Der Launch ist der Anfang, nicht das Ende. Eine Anwendung, die fünf Jahre laufen soll, verbringt den größten Teil dieser Zeit im Betrieb – und die Entscheidungen, die diesen Betrieb teuer oder ruhig machen, fallen fast alle vorher. Was wir aus Projekten mitnehmen, die wir übernommen haben, lässt sich auf vier Punkte zusammenziehen.
Updates ohne Angst
Laravel veröffentlicht jedes Jahr eine neue Hauptversion, jede davon mit einem klar dokumentierten Upgrade-Pfad. Wer ihm jährlich folgt, hat jedes Mal einen überschaubaren Nachmittag Arbeit. Wer drei Versionen überspringt, hat ein Projekt.
Der Grund, warum Updates aufgeschoben werden, ist selten Bequemlichkeit. Es ist Unsicherheit: niemand weiß, was danach kaputt ist. Genau deshalb hängt dieser Punkt am nächsten.
Tests als Sicherheitsnetz, nicht als Selbstzweck
Eine hundertprozentige Testabdeckung ist kein sinnvolles Ziel und für die meisten Projekte auch kein bezahlbares. Was Sie brauchen, ist etwas anderes: Tests für die Wege, die Geld kosten, wenn sie brechen. Der Bestellvorgang. Der Login. Die Schnittstelle zur Warenwirtschaft. Der nächtliche Import.
Diese Tests beantworten nach jedem Update genau die Frage, die sonst niemand beantworten kann – läuft das noch. Laravel bringt dafür alles mit, was nötig ist; die Hürde ist nie das Werkzeug, sondern die Entscheidung, die Zeit dafür einzuplanen.
Deployments, die niemand fürchtet
Wenn ein Deployment ein Ereignis ist, für das man einen ruhigen Freitagnachmittag sucht, wird zu selten deployt. Und je seltener deployt wird, desto größer ist jedes Mal die Änderungsmenge – und desto größer das Risiko. Das ist eine Spirale, die sich selbst verstärkt.
Der Ausweg ist unspektakulär:
- ein Skript statt einer Schrittfolge im Kopf, damit jeder Durchgang gleich abläuft
- Migrationen, die rückwärts genauso funktionieren wie vorwärts
- ein Weg zurück zur vorherigen Version, der geprobt ist und nicht nur existiert
- Konfiguration in Umgebungsvariablen, nicht im Code
Nichts davon ist aufwendig, wenn es von Anfang an so gebaut ist. Alles davon ist mühsam, wenn es nachträglich kommt.
Wann ein Neubau billiger ist
Manchmal ist die ehrliche Antwort, dass Weiterpflegen teurer wird als Ersetzen. Dafür gibt es Anzeichen, die sich benennen lassen: Die PHP-Version wird nicht mehr mit Sicherheitsupdates versorgt. Zentrale Pakete werden nicht mehr gepflegt. Jede Änderung an einer Stelle bricht zwei andere. Niemand im Team traut sich mehr an einen bestimmten Bereich.
Trifft davon eines zu, ist es ein Warnsignal. Treffen drei zu, rechnen Sie beides durch. Ein schrittweiser Umbau – neue Teile neben dem Bestand, Stück für Stück umgehängt – ist dabei fast immer der ruhigere Weg als ein Schnitt, bei dem alles gleichzeitig neu ist.
Das Muster hinter allen vier Punkten ist dasselbe: Betriebskosten entstehen nicht im Betrieb. Sie entstehen in den Entscheidungen davor.