Jede Version, die ihre Prüfung besteht, geht live
· 3 Min. Lesezeit
Wenn wir eine Verbesserung ausliefern, sollst du sie innerhalb von Minuten haben, nicht irgendwann. Heute haben wir die letzte Meile unserer Release-Kette um dieses Versprechen herum neu gebaut. Eine Version, die ihren Gesundheitscheck besteht, erreicht dich jetzt immer, und das Sicherheitsnetz, das dich vor einer schlechten Version schützt, greift nur, wenn es soll.
Was eine Version beweisen muss
Unsere Release-Kette hat eine vertraute Form. Sie baut die neue Version, startet sie neben der aktuellen, prüft, ob sie gesund antwortet, und lässt sie erst dann ausliefern. Besteht die neue Version diese Prüfung nicht, schickt ein Sicherheitsnetz die Besucher zurück zur vorherigen.
Das sind zwei Versprechen, nicht eines. Eine gesunde Version muss live gehen, eine kranke nicht. Diese Woche, beim Ausliefern der neuen Videoplanung pro Website, haben wir beide genau geprüft: Das zweite war stark, das erste beruhte auf einer Annahme.
Wir wollten, dass eine gesunde Version unmöglich in den Kulissen warten kann. Also sind wir jeden Schritt durchgegangen, der entscheidet, wohin der Verkehr geht.
Ein Sicherheitsnetz mit präzisem Auslöser
Ein Sicherheitsnetz ist nur so gut wie sein Auslöser. Unseres griff, sobald irgendein früherer Schritt gescheitert war, auch Schritte, die laufen, bevor eine neue Version überhaupt jemanden bedient, etwa der Build selbst. Dann gibt es nichts zurückzurollen, und das Eingreifen schadet mehr, als es nützt.
Wir haben es auf den einen Moment eingegrenzt, für den es gedacht ist: Eine neue Version ging live und bestand dann ihre Gesundheitsprüfung nicht. Hat ein früheres Problem diese Prüfung gar nicht erst laufen lassen, hält sich das Netz jetzt heraus.
Der Test des neuen Auslösers mit einer absichtlich fehlschlagenden Prüfung zeigte uns zwei Feinheiten, und wir haben beide behoben:
- Der Schritt, der sich die gerade ausliefernde Version merkt, wählt jetzt die, die tatsächlich Verkehr trägt, nicht einfach die erste in der Liste.
- In GitHub Actions ist eine Bedingung, die keinen Status nennt, stillschweigend auf den Fall beschränkt, dass alles geklappt hat. Eine Rollback-Bedingung muss
failure()ausdrücklich nennen, sonst kann sie nie greifen, wenn es darauf ankommt.
Der Verkehr geht immer zur neuesten Version
Die tiefere Erkenntnis betraf, wie unsere Hosting-Plattform, Cloud Run, den Verkehr verteilt. Standardmäßig liefert sie die neueste gesunde Version aus. Lenkt man aber den gesamten Verkehr auf eine benannte Version, wie es ein Rollback tut, merkt sich die Plattform diese Wahl und liefert weiter diese Version aus, auch wenn neuere hinzukommen.
Das ist ein vernünftiges Verhalten, und es bedeutete, dass unsere Kette nicht einfach annehmen konnte, die neueste Version sei die ausliefernde.
Also haben wir den Schritt ergänzt, der aus der Annahme eine Garantie macht. Am Ende jedes Deployments sagt die Kette der Plattform, dass sie die neueste Version ausliefern soll. Was auch immer vorher geschah, ein Rollback, ein Test, eine manuelle Änderung: Ein erfolgreiches Release endet damit, dass die gerade ausgelieferte Version vor dir steht. Aus einer Hoffnung wurde etwas, das jedes Deployment ausdrücklich festlegt.
Saubere Builds, jedes Mal
In derselben Woche haben wir ein weiteres Detail geschärft. Unsere Versionen werden aus einer sauberen Kopie des Codes gebaut, nicht vom Rechner eines Entwicklers, also muss eine Änderung im Commit selbst vollständig sein. Ein Typ-Import, der auf dem Rechner blieb, während seine Funktion in den Commit ging, hat uns gezeigt, wie leicht man das übersieht.
Die Lösung war eine Import-Zeile, und die Gewohnheit, die sie gestärkt hat, ist mehr wert. Bevor ein Commit hinausgeht, prüfen wir ihn in einer sauberen Kopie, genau so, wie der Build ihn sieht, und nicht in einem Arbeitsordner voller anderer Änderungen.
Zusammen machen diese Änderungen Releases für alle ruhiger:
- ein Build, der nicht fertig ist, erreicht dich nie,
- eine gesunde Version erreicht dich immer,
- und eine Version, die nach dem Livegang stolpert, wird binnen Augenblicken durch die vorherige ersetzt.
Was das für dich bedeutet
Du wirst nichts davon sehen, und genau darum geht es. Wenn wir in diesem Blog schreiben, dass etwas heute ausgeliefert wurde, ist es heute live, für jeden Film, den du machst. Die Planung pro Website, mit der diese Arbeit begann, Ideen und Shotlisten für jede hinzugefügte Seite, kam noch am selben Nachmittag bei allen an.
Für alle, die eine eigene Release-Kette betreiben, ist die Lehre kurz. Ein Sicherheitsmechanismus ist auch Code und verdient dieselben Tests wie das, was er schützt, in genau der Lage, für die er geschrieben wurde. Und eine grüne Kette beweist, dass die Schritte gelaufen sind: Lass einen dieser Schritte beweisen, dass die neue Version die ausliefernde ist.
Verfolge jede Neuerung, sobald sie erscheint, im Blog.
Sieh es auf deiner eigenen Website
Füge eine Seite ein und bekomme das vertonte Video, um das es in diesem Blog geht. Das erste ist kostenlos.
Weiterlesen
