Im Januar startete das Projekt, Anfang Mai war schon der Go-Live und zwischendurch sollte immer mehr bekannt werden - wie realisiert man eine fortwährende Weiterentwicklung ohne gleich ständig die produktive Webseite zu stören?

Releases und Staging

Dazu habe ich ein zweistufiges Staging eingesetzt: eine Site stellt den Entwicklungsstand dar, der bis zu einem Release weiterentwickelt wird, eine andere Site ist dann die produktive Site, die den letzten Stand anbietet. Für die Webseite att-digital.de habe ich einen zweiten Webauftritt innerhalb einer eigenen Domäne aufgebaut, um die Seiten ungestört aufbauen zu können und zum gewünschten Zeitpunkt als neues Release publizieren zu können. Dieses "Staging"-Verfahren ist in der industriellen Softwareentwicklung weit verbreitet. Der Aufbau von neuen Seiten geschah also innerhalb der Testumgebung mit einer eigenen Joomla-Instanz.

Nach Definition eines Fertigungsstands wurde mit akeeba backup die Site komplett in die produktive Umgebung transportiert und dort geladen. Akeeba Backup hat diesen Prozess deswegen gut unterstützt, weil alle Domain-spezifischen Elemente (Datenbank-Einstellungen, bestimmte User-Einstellungen, Site-URL) vor der Aktivierung der Site eingestellt werden konnten - ich hatte sie der Bequemlichkeit halber einfach in einem Dokument lokal gespeichert und konnte diese mit Copy&Paste immer wieder bei jedem Release-Gang übertragen.

Warum ist dieser Staging-Weg sinnvoll? Aus diversen Gründen kann man sich das Layout der Site "zerschießen"; eine falsche Einstellung und ein amoklaufendes Modul oder Plugin kann dafür sorgen, dass Teile des Webauftritts unbrauchbar werden. Darum habe ich in regelmäßigen Abständen ein Backup des aktuellen Standes ausgeführt, denn meine Freizeitarbeitszeit war kostbarer als die benötigte, kurze Wartezeit für das Backup. Dieses Backup habe ich anschließend an mindestens 2 weitere Orte transferiert (Hinweis: akeeba Backup löscht in der Standardeinstellung Backups, die älter als drei Versionen sind).

War das sinnvoll? Ja, an mindestens zwei Situationen kann ich mich erinnern, in denen der erneute Aufbau der geplanten Seite aufwändiger gewesen wäre als das Wiedereinspielen des Backups und der anschließenden Vermeidung des potenziellen Fehlers.

No way of return?

Der Standardweg war also die Übertragung des neuen Release-Standes von der Test-Site zur produktiven Site. Geht auch die umgekehrte Richtung?

Die größte Dynamik hatte der Seitenaufbau der Ausstellerseiten (s.u.). Die Aussteller haben sich an der produktiven Site angemeldet und ihren Daten übertragen (die Test-Site sollte von ihnen nicht benutzt werden).  Dadurch entstand eine Situation, in der die Benutzerdaten auf der produktiven Site aktueller waren als auf der Test-Site. Joomla 3 fasst aber alle wichtigen Elemente in genau einer Tabelle (<i>präfix</i>-users) zusammen - wenn man beim Site-Transfer von der Test-Site zur produktiven Site nichts Ungewünschtes überschreibt, kann man sich ein lässtiges Transferieren der Ausstellerdaten zur Test-Site übertragen - beim Importieren muss man nur die Tabellen ausklammen, die nicht überschrieben werden sollen. Glücklicherweise speichert Joomla 3 das Benutzerpassword als Hash; dieser Eintrag lässt sich einfach auch über ein SQL Statement (bspw. in phpAdmin) übertragen. Also war nicht nur der Weg von der Test-Site zur produkiven Site möglich, sondern auch die umgekehrte Richtung ließ sich verwenden. Übrigens habe ich beim Import grundsätzlich "Drop Table" verwendet; ich wollte mich nicht um ein Durcheinander kümmern müssen.