Upgrade des Drupal-Core

Wechsel einer Drupal-Hauptversion ohne Datenverlust

Ein Upgrade des Drupal-Core ist erforderlich, wenn von einer Hauptversion wie Drupal 5.x auf Drupal 6.x oder von Drupal 6.x auf Drupal 7.x aktualisiert werden soll. Ein solches Upgrade zieht grundsätzlich eine Aktualisierung sämtlicher Zusatzmodule und meist auch des Themes mit sich. Hier gibt es zwei Problemfälle:

  • In vielen Fällen stellen die Modulentwickler aktualisierte Versionen ihrer Module zur Verfügung; meist gibt es Migrationspfade, die Datenstrukturen an die neue Modulversion anpassen. Wenn ein Modul jedoch nicht mehr weiterentwickelt wird, steht der Anwender häufig im Regen und muss sich selbst um die Migration seiner Daten kümmern.
  • Je komplexer Drupal-basierte Web-Anwendungen werden, desto häufiger sind die vom Modul bereitgestellten Migrationspfade überfordert. Das betrifft insbesondere die hochkomplexen Umstellungen von CCK-Inhaltstypen von Drupal 5 und 6 auf die Entity-basierten Felder in Drupal 7.

Stehen bei Ihnen komplizierte Versionswechsel an, helfen wir Ihnen bei der Datensicherung, bei der Aufwandsabschätzung und bei eventuell anfallenden individuellen Migrationsarbeiten.

Unsere Vorgehensweise für ein Upgrade von Drupal Core ist dabei typischerweise wie folgt:

  1. Datensicherung.
    • Backup/Restore. Vor jeden Migrationsprojekt wird zunächst eine vollständige Datensicherung von Dateisystem und Datenbank durchgeführt, getestet und archiviert. So lange nicht sichergestellt ist, dass sich die Website vollständig wiederherstellen lässt, wird kein Upgrade durchgeführt.
  2. Prüfvorlauf. Jedes größere Upgrade wird in einer isolierten Testumgebung geprüft; der Betrieb des Live-Servers wird durch das Upgrade nicht beeinträchtigt.
    • Einrichten einer Testumgebung. Aus dem aktuellen Backup wird eine Testumgebung erzeugt, die die Live-Umgebung möglichst weitgehend nachbildet.
    • Aufwandsanalyse. In der Testumgebung wird der Aufwand für die mit einem Upgrade verbundenen Arbeiten analysiert. Hier wird auch geprüft, welche Zusatzmodule problemlos aktualisiert werden können, ob individuell entwickelte Module portiert werden müssen und ob das vorhandene Theme portiert werden kann. Die Ergebnisse dieser Analyse werden mit dem Klienten diskutiert und gewichtet; wenn gravierende Argumente gegen ein Upgrade sprechen, werden Alternativen entwickelt, oder das Upgrade vorerst zurückgestellt.
    • Portieren individueller Anpassungen. Sofern individuelle Portierungen von Modulen oder Themes erforderlich sind, werden separate Teilprojekte initiiert. Sofern die fehlenden Komponenten funktionskritisch sind, wird das Upgrade erneut zurückgestellt.
    • Upgrade der Testumgebung. Mit den duplizierten Daten des Live-Servers wird in der Testumgebung ein Upgrade durchgeführt, der Verlauf protokolliert und anschließend analysiert. Bei komplexeren Websites ist mit an Sicherheit grenzender Wahrscheinlichkeit damit zu rechnen, dass die ersten Testläufe fehlschlagen oder zumindest keine zufriedenstellenden Ergebnisse liefern. Die Ergebnisse werden Klienten besprochen; an der Upgrade-Prozedur werden so lange Anpassungen vorgenommen, bis ein zufriedenstellendes Upgrade reproduzierbar wird.
    • Validieren der aktualisierten Website. Die aktualisierte Website wird - noch immer in der testumgebung - stichprobenartig validiert. Bei sensitiven Daten müssen ggf. individuelle Prüfroutinen entwickelt werden, mit denen die Konsistenz der Daten sichergestellt ist. Spätestens zu diesem Zeitpunkt muss auch das portierte Theme voll funktionsfähig zur Verfügung stehen.
    • Nachbearbeitung. Bei vielen Upgrade-Projekten werden nun manuelle Nacharbeiten erforderlich, beispielsweise bei der Konfiguration von Core- und Zusatzmodulen. Sofern auch hier sichergestellt ist, dass die erforderlichen Funktionalitäten zur Verfügung stehen, wird der Prüfvorlauf abgeschlossen.
  3. Finales Upgrade. Auch die tatsächliche Migration wird nicht auf dem Live-Server, sondern in der Testumgebung durchgeführt. Achtung - in bestimmten Fällen (z.B. E-Commerce-Sites) kann es nicht praktikabel sein, isolierte Updates durchzuführen; hier müssen häfig individuelle Lösungen entwickelt werden.
    • Parallelbetrieb. Auf dem Live-Webserver wird die aktualisierte Website eingespielt und ist nun unter einer separaten DNS-Adresse wie
      beta.meinserver.de
      erreichbar.
    • Validierung und Nachbearbeitung. Die Prüf- und Konfigurationssschritte der Testumgebung werden nun im Pseudo-Livebetrieb repliziert.
    • Wenn die aktualisierte Website unter
      beta.meinserver.de
      zufriedenstellend läuft, wird der DNS-Eintrag geschwenkt: Aus
      beta.meinserver.de
      wird
      www.meinserver.de
      , und aus dem alten
      www.meinserver.de
      wird
      legacy.meinserver.de
      .
    • Abschließende Validierung und Nachbearbeitung. Sofern noch weitere Nacharbeiten durch den DNS-Schwenk erforderlich sind, schließen diese den Upgrade-Prozess ab.

Upgrade auf Drupal 7

Das Upgrade von Drupal 6 auf Drupal 7 ist das bisher mit Abstand komplizierteste der Drupal-Geschichte: Aufgrund der langen Entwicklungszeit haben sich sehr viele interne Änderungen ergeben.

Upgrades von Drupal 6 auf Drupal 7 schließen häufig ein Upgrade von CCK auf Entity-basierte Felder im Drupal-Kern ein. Für diese Aktualisierungen sind praktisch immer zusätzliche Migrationsarbeiten erforderlich.

Hinweise zum Upgrade auf D7:

  • Wann ist der beste Zeitpunkt für ein Upgrade? - Eine kleine Checkliste