Wie aktualisiert man ein TYPO3 System, ohne einen Scherbenhaufen zu hinterlassen? Eigentlich gibt's ja hierfür auch Systemunterstützung von TYPO3, doch wer seinen Job auch morgen noch haben will, verlässt sich lieber nicht auf solche Autopiloten.

Für eine große und komplexe TYPO3-Installation hat CosmoCode jüngst ein Update durchgeführt. Groß meint in diesem Fall:

• Seit über 5 Jahren in Betrieb
• Mehr als 6 Portale unter einem Dach
• Viele unterschiedliche Dienstleister, die über die Jahre mitgewirkt haben
• Über 150 Extensions im Einsatz (sic! wir können es selber kaum glauben)
• 20 beteiligte Redakteure mit permanenter Arbeit am System

Die Aufgabe bestand darin, das veraltete 4.2.6 System auf die neueste Version 4.5.2 zu aktualisieren. Wichtigste Motivation hierbei ist die Tatsache, dass für die alte Version kein Support mehr geleistet wird - Sicherheitslücken bleiben also ungepatched. Für die 4.5.2'er Version dagegen wird ein Support von 3 Jahren geboten („long term support“)

Der Ablauf des gesamten TYPO3 Update Prozesses wurde in mehrere Schritte geplant und durchgeführt:

• Aufbau Migrationssystem
• Durchführung Update
• Bestandsaufnahme Frontend + Backend
• Patch & Fix
• Liveschaltung

Bei komplexen TYPO3 Systemen mit individuellen Anpassungen und Workarounds sind natürlich Schwierigkeiten zu erwarten. Um den laufenden Betrieb nicht zu stören, haben wir uns entschlossen eine separate TYPO3 Infrastruktur (identisch zum Produktionssystem) aufzubauen, in welcher das Upgrade durchgeführt wird.

Dass man das Update nicht im Livesystem durchführt ist klar. Aber könnte man das nicht auch im Entwicklungs- oder Integrationssystem durchführen? Wir haben uns dagegen entschlossen, um alle Workflows - einschließlich der Entwicklung neuer TYPO3 Komponenten - über einen längeren Zeitraum wie gehabt durchführen zu können. Das hat uns Zeit und dem Kunden Ruhe verschafft.

Normalerweise sieht ein Update so aus: tarball entpacken, um Kern und Systemextensions zu aktualisieren.

In TYPO3 gibt's im Install Tool einen Update Wizard, der einem dabei hilft die unterschiedlichen DB Schemas anzugleichen.

Leider scheiterte der Durchlauf an einem Bug des Wizards: Dieser wollte partout bestimmte fehlende Datenbankspalten vom typ TEXT anlegen, in einer TYPO3 Neuinstallation waren diese aber als VARCHAR vorgesehen. Zum Glück scheiterte der Wizard dann daran, dass er keine Primary Keys auf TEXT Felder setzen kann - ohne diesen Fehler im Fehler wäre das unbemerkt geblieben und hätte später nur mühsam identifiziert werden können.

Übrigens:

• Dieser Fehler wurde mittlerweile in der TYPO3 Version 4.5.2 behoben.
• Das Tool informiert auch über die Verfügbarkeit von Updates der Systemextensions und bietet einen Migrationsassistenten für Templates an. Wie haben das allerdings nicht gemacht und lieber Schritt für Schritt die Anpassungen selber vorgenommen.

Nach der Durchführung des Updates haben wir Frontend und Backend detailliert untersucht. Bei zwei Portalen gab es kritische Fehler, die wir ad hoc gefixt haben; alle anderen Auffälligkeiten wurden im Ticketsystem notiert.

Nicht alle Dinge haben die gleiche Priorität für den Kunden und nicht für alle Korrekturen ist Budget da. Nach unserer Prüfung hat dann der Kunde seinerseits die Frontendkomponenten und Backendfunktionen geprüft und ebenfalls im Ticketsystem proktokolliert, wo wir dann unsere Aufwandsschätzungen zur Behebung nachgetragen haben.

Als kleiner Appetitanreger hier ein Auszug aus der Fehlerliste:

• …
• Ticket #11: mailformplus verursacht schwerwiegende Fehler und behindert Seitendarstellung
• Ticket #13: Bilder mit Sonderzeichen im Namen werden vom Typosystem fehlerhaft an ImageMagick übergeben und im FE/BE nicht angezeigt
• Ticket #14: Fehlerhafte Anzahl an Suchergebnissen bei IndexedSearch
• Ticket #15: Seitenfehler „Seite nicht gefunden“, „page not accessible“
• Ticket #16: generic markers werden nicht geparsed/angezeigt
• Ticket #17: tx_comments funktioniert nicht mehr auf XYZ
• Ticket #18: XYZ: fatal error durch falschen TypoScript Typ
• Ticket #19: Newsletter-Seiten-Voransicht: Cannot unset string offsets
• Ticket #20: Extension „frontend user registration“ verursacht einen Fehler bei der Validierung der E-Mail-Adresse
• Ticket #21: Die Sprache im Backend ist nicht komplett auf Deutsch
• Ticket #22: Felder für Lightbox-Einstellungen erscheinen nicht im Backend
• Ticket #23: Upgrade Wizard DB Compare: BLOB/TEXT column used in key specification without a key length
• Ticket #25: Link-Text wird aus Überschrift/Titel übernommen wenn kein Linktext gesetzt wurde
• …

u.s.w. und so fort….

Nun wurden die mit den Kunden abgesprochenen Probleme gelöst. Hilfreich war natürlich die Analyse der Fehlermeldungen, die häufig auch im TYPO3 BugTracker wiedergefunden wurden und uns Lösungsansätze brachten. Die Probleme lassen sich grob in drei Klassen aufteilen:

• Einige Probleme mit diversen Extensions; dies konnte in der Regel mit Extension Updates behoben werden. Häufig musste aber manuell nachgearbeitet werden, da über die Jahre in den Extensions von Dienstleistern individuelle Workarounds eingebaut wurden.
• Fehler im TYPO3 Kern (bedingt durch eine veraltete Programmierung) - diese konnten durch einen inoffiziellen Patch gefixt werden.
• Probleme mit dem leidigen TypoScript - die in unserem System verwendete Notation war stellenweise veraltet und musste manuell migriert werden.

Nachdem im Migrationssystem alle identifizierten Probleme gelöst wurden, konnte das eigentliche Update durchgeführt werden.

Dieses haben wir auf dem Produktionsserver in einer separaten Installation vorbereitet und durchgeführt. Auch hier gab es noch einmal Probleme, die ausschließlich auf dem Produktionsserver auftraten. Der eigentliche Content Freeze betrug 3 Tage, in denen keine redaktionelle Arbeit durchgeführt werden konnte. User Generated Content der in diesem Zeitraum anfiel, wurde manuell nachgetragen.

Dann endlich konnte der Hebel umgelegt und das neue migrierte Livesystem scharf geschaltet werden!

Die Vorgehensweise erwies sich nachträglich als richtig. Die gründliche Planung, die Bestandsaufnahme und das separate Migrationssystem haben uns die nötigen zeitlichen und technischen Freiräume für die erfolgreiche Durchführung geschaffen. Auch bei der Schätzung der Aufwände zur Behebung der durch das Update hervorgerufenen Probleme lagen wir ganz gut - unsere Schätzung wich nur etwa 15% von der Realität ab.

Festzuhalten ist allerdings, dass für ein solches Vorgehen das Vertrauen des Kunden nötig ist - üblicherweise soll ja ein Festpreisangebot erstellt werden. Aber selbst wenn man TYPO3 seit Jahren kennt und auch mit dem Kundensystem vertraut ist - ein Update ist ein Risiko. Mit unserem Vorgehensmodell lässt es sich zumindest während der Projektes in eine handhabbare, kalkulierbare Form bringen.