© Ozz Design/Shutterstock.com
Warum frühere Best Practices im Deployment nicht mehr funktionieren

Nichts bleibt, wie es war


In der Tech-Welt wird oft von „Best Practices“ gesprochen, aber selten wird anerkannt, dass diese sich im Laufe der Zeit ständig weiterentwickeln und verändern. Alle Best Practices sind nichts anderes als eine Destillation der Herausforderungen einer gegebenen Situation zu einem normalerweise optimalen Kompromisspaket. Beste Beispiele dafür sind die Development-Workflows.

Mit dem technologischen Fortschritt ändern sich gemachte Kompromisse. Was früher kompliziert und teuer war, kann einfacher und billiger werden (und manchmal kann das, was früher einfach und billig war, kompliziert und teuer werden). Das bedeutet, dass sich Best Practices mit technologischem Fortschritt weiterentwickeln müssen. Was einst der Vorreiter war, kann mittlerweile verlustbringend sein.

Das 3-Stufen-Deployment-Modell

Ein Beispiel für eine solche Entwicklung sind die Development-Workflows. Früher waren Serverumgebungen teuer und zeitaufwendig im Aufbau und in der Wartung. Sie erforderten physische Hardware, manuelle Installation von Software und manuelle Pflege, um auf dem neuesten Stand zu bleiben. Das war damals eine Rechtfertigung dafür, nur ein Produktivsystem zu haben und sonst nichts. Das führte zu einem Entwicklungsmodell von „meinem Desktop und der Produktion“ oder „nur Produktion“, wenn man kein Glück hatte. Alles, was robuster, aber zeitintensiver war, lohnte sich für kleinere Installationen nicht.

Im Laufe der Zeit wurde der Branche klar, dass dies ein schlechter Kompromiss war. „Hack it on production“ wurde durch das berühmte 3-Stufen-Modell (Abb. 1) Dev ➞ (Testing) ➞ Staging ➞ Prod ersetzt (bzw. manchmal auch durch ein 4-Stufen-Modell, wenn man das Budget hatte):

  1. Bei der Entwicklung wird Code bearbeitet, normalerweise auf dem lokalen Computer des Entwicklers.

  2. Beim Testing wird der Code mehrerer Entwickler zusammengeführt. Hier finden Integrationstests, Benutzerakzeptanztests und andere QA-Tests statt. Manchmal wird diese Etappe mit Staging kombiniert.

  3. Staging ist ein Vorveröffentlichungswartebereich, in dem der Code in einer produktionsähnlichen Umgebung getestet wird.

  4. Production ist die Livewebseite.

garfield_deployment_1.tif_fmt1.jpgAbb. 1: Das 3-Stufen-Modell

Der Vorteil des 3/4-Schichten-Modells besteht darin, dass der Code von mehreren Personen überprüft und getestet werden kann, bevor er die Livesite erreicht. Der Witz dabei: Jeder hat einen Testserver; einige Leute haben das Glück, auch einen separaten Produktionsserver zu haben. Das ist ein Fortschritt gegenüber dem Arbeiten auf der Produktivumgebung. Es bedeutet auch, dass es einen spezifischen Schritt gibt, bei dem eine bestimmte Aktivität stattfindet: Das Schreiben von Code geschieht in Dev; das Zusammenführen von Code geschieht in Testing; QA geschieht in Testing; die abschließende Überprüfung geschieht in Staging, manchmal mit einer vorherigen Sicherung der Produktionsdaten; und die Produktivumgebung ist der Ort, an dem Kunden die Webseite tatsächlich sehen.

Das 3-Stufen-Modell hat jedoch auch eine Reihe von Nachteilen. Insbesondere ist es für die lokale Entwicklung sehr leicht, weit hinter der Testing-Instanz zurückzufallen, was dazu führt, dass sich Testing zu einer Masse von Merge-Konflikten entwickelt. Je länger man mit dem Zusammenführen von Code im Testing wartet, desto schwieriger wird es. Auf der anderen Seite wird das Testing umso schwieriger, je häufiger Sie den Code im Testing zusammenführen. Das zu testende Feature kann sich jedes Mal ändern, wenn neue Codes zusammengeführt werden, was zu einem beweglichen Ziel führt. Die Herausforderung wächst, wenn Sie mehrere Tester haben, da deren Arbeit kollidiert. Das gilt insbesondere für Tests mit Endbenutzern oder für Tests, bei denen Daten geändert werden müssen.

Der andere große Nachteil dieses Modells ist, dass es linear ist. Damit Code in die Produktionsumgebung gelangen kann, muss er Tests und/oder Staging durchlaufen, von denen es nur jeweils eines gibt. Das kann in Ordnung sein, wenn alles funktioniert, aber natürlich geht auch einmal etwas schief. Wenn Sie einen Fehler in der Produktionsumgebung entdecken, ist es eine schlechte Idee, die Test- und/oder Staging Pipeline zu umgehen und direkt die Produktionsumgebung zu aktualisieren, ohne zu überprüfen, ob der Fix nicht noch etwas anderes kaputt macht. Wenn Sie jedoch die korrekten Test- bzw. Staging-Phasen durchlaufen, könnte Ihr einfacher Fix durch eine andere, noch nicht fertige Funktion blockiert werden, die bereits mit Testing oder St...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang