Kopie von Drupal automatisiert erstellen

Den Aufwand mache ich mir nicht.

Ich habe bei mir lokal einen Subversion Server laufen in dem alle Drupaldateien enthalten sind.
Das Einzige was ich mir immer lade ist die aktuelle DB, die Entwicklungsumgebung + DB läuft immer lokal, genauso wie die Tests.
Nach erfolgreichem Test übertrage (commite) ich dann alles in Subversion und die Dateien werden danach entsprechend hochgeladen, natürlich auch nur die, die ich angepasst habe.
So verfahre ich auch bei einem Drupal Update.

Es geht dir ja darum, auch nach Veränderungen noch auf die vorige(n) Version(en) zuzugreifen. Genau dafür wurde Version Control Software erfunden. Mit VCS wie git kannst du dir deine Arbeit deutlich vereinfachen. Du kannst damit auf beliebige Versionen der Vergangenheit zurückgreifen und sogar verschiedene Projektzustände (Entwicklung, Test, Produktion) parallel halten.

Mit der push-Funktion von git kannst du dein lokales Projekt bequem auf den Webserver ausrollen. Diesen Weg nutzen wir auch für die Website-Pflege auf unseren Drupal-Clustern.

Mit etwas Mühe kannst du sogar das DB-Backup mit dem VCS verknüpfen, sodass beim Rollout automatisch ein Backup gezogen wird.

Ich bin überzeugt, dass sich die Einarbeitung lohnt.

Besten Gruß,
Jochen

Dank für die Tipps mit der Versionierung! Das schaue ich mir auf jeden Fall mal an!

Die Versionierung bezieht sich dann nur auf Dateien, die ich verändere, oder? Also z.B. wenn ich css oder tpl Dateien ändere oder Module hinzufüge.

Wie schaut es aber mit inhaltlichen Änderungen aus? Die mache ich ja nicht in Dateien, sondern in Drupal (d.h. im Browser) und Drupal speichert die Sachen in der mysql DB.

Kann ich hier auch irgendwie einen Mechanismus einbauen, dass meine inhaltlichen Änderungen "comitted" werden, ich also nicht alles ein zweites Mal eingeben muss?

Meinst Du so eine Art Staging System, also Inhalte lokal ändern und diese dann entsprechend an die Online-DB übertragen, natürlich hier auch nur die geänderten?

Es kommt darauf an, welche Änderungen du genau meinst. In der Datenbank mischen sich ja Inhalte (in der Hauptsache Nodes) mit Metadaten (z.B. Inhaltstypen und Views). Damit letztere versioniert werden können, wurde das Features-Modul entwickelt. Es exportiert die gewünschten Informationen und erstellt daraus ein Drupal-Modul, das du dann ganz normal installieren, versionieren usw. kannst. Damit habe ich z.B. ein Fotoalbum-Modul/Feature aus den dafür notwendigen Inhaltstypen, Views, Imagecache-Presets, Modul-Abhängigkeiten usw. zusammengestellt und kann es jetzt ganz einfach wiederverwenden.

Echten Content kannst du zumindest als SQL-Dump der entsprechenden Nodes versionieren.

Besten Gruß,
Jochen

Hallo,

sorry, ich glaube, ich verstehe den vorgeschlagenen Lösungsansatz noch nicht richtig.
Ich glaube folgendes verstanden zu haben:

1) Einen lokalen Web-Umgebung (z.B. XAMP) aufbauen und dort alle Änderungen durchführen.
2) Zusätzlich zum XAMP noch einen lokalen Versionierungs-Server verwenden.
3) Dieser Versionierungsserver ist dann in der Lage, die Änderungen auf Befehl (commit) auf den Server beim Hoster zu schicken.

Soweit richtig?

Wenn ich Inhalte ändere, mache ich das auch lokal. Wie kommen diese dann zum Hoster. Dort nochmal eingeben via copy & paste?

Danke für eure Geduld...
Grüße, wakeup

Vllt. meldest du dich mal Acquia kostenlos für das heutige Webinar an. Da geht es nämlich ganz genau um Staging Systeme. Ich bin leider verhindert. Müsste 19 Uhr deutscher Zeit losgehen.....

Der Link

Ich hatte gestern Abend auch einen anderen Termin und konnte leider nicht teilnehmen. Ich hoffe, jemand kann mir zu meinen vorigen Fragen antworten. Ich bin übrigens nur eine Person, die die Seite pflegt. Aber ich möchte bei größeren Änderungen eben nicht direkt auf der produktiven Seite schrauben, sondern erst mal testen.

Ja, deine drei Punkte fassen es gut zusammen. Du hast zwei Drupal-Installationen: eine lokale zum Arbeiten und eine produktive auf dem Webserver. Die Dateien der Installation verwaltest du mit einem VCS wie git oder Bazaar. Änderungen kannst du manuell durchführen oder es dir mit Drush deutlich einfacher machen.

Zunächst nutzt du am besten die üblichen Wege zum Upload deiner Dateien. Ein fortgeschrittenes Beispiel, wie git durchgängig zum Deployment genutzt werden kann, gibt der Artikel "Website maintenance with git, the pro way".

Inhaltliche Änderungen spielen sich nicht im Dateisystem, sondern in der Datenbank ab. Dazu habe ich weiter oben schon etwas geschrieben. Eventuell helfen dir dabei die Drush-Funktion "sql-sync" oder das Modul backup_migrate.

Beste Grüße,
Jochen

Ich hätte dazu auch eine Frage.

Mit mysqldumper kann man ja - zeitgesteuert - die Datenbank sichern - wie sieht es aber mit dem files-Ordner aus?

Wenn sich bei mir User anmelden, laden sie für gewöhnlich einige Fotos hoch (fürs User-Profile) - sollte mal der Server crashen oder abgeschossen werden, habe ich zwar immer eine aktuelle SQL-Datenbank (welche 2mal täglich per mysqldumper auf einen anderen Server hochgeladen wird) aber die Bilder/Fotos aus dem files-Ordner fehlen dann sodass mir die Datenbanksicherung alleine garnicht all zu viel bringt.

Gibt es ein Modul/Script/Software mit der/dem man auch den files-Ordner zeitgesteuert sichern und auf einen anderen Server hochladen lassen kann?

Schöne Grüße
Matthias

http://drupal.org/project/backup_migrate ist mittlerweile wirklich sehr komfortabel (und tatsächlich auch zuverlässig) für alle, die nicht in git etc. einsteigen wollen ...