Wie wir ohne Ausfallzeit ausliefern

Releases sollten für Ihre Nutzer unsichtbar sein. Ein Blick auf die Rollout-Strategie, die uns ohne Wartungsfenster deployen lässt.

Technik

Technik

Deployen ohne Drama

Nutzer sollten nie merken, dass ein Release geschah.

Wir rollen Änderungen schrittweise hinter Health-Checks aus, halten einen schnellen Rückweg und migrieren sorgfältig, sodass Deploys ein routinemäßiges, umkehrbares Nicht-Ereignis sind statt einer geplanten Auszeit.

Wie der Wechsel unsichtbar bleibt

Rollierender Rollout

Neue und alte Version laufen gemeinsam, während der Verkehr wandert.

Sofortiges Rollback

Jedes Release lässt sich umkehren, sobald es sich falsch verhält.

Gesundheitsgeprüft

Automatische Checks müssen bestehen, bevor mehr Verkehr wandert.

Das Ziel

Das beste Release bemerkt niemand

Wartungsfenster sind das Versprechen, Ihre Nutzer zu unterbrechen.

Das System für ein Update abzuschalten sagt Kunden, ihre Arbeit komme an zweiter Stelle. Wir deployen umgekehrt: neuer Code läuft neben dem alten, der Verkehr wandert schrittweise, und der Wechsel bleibt von außen unsichtbar.

Sieht während des Rollouts etwas falsch aus, rollen wir ebenso leise zurück, ein schlechtes Release kostet Sekunden Vorsicht, keinen Ausfall.

Highlights

So funktioniert es

Schrittweiser Rollout

Neuer Code erreicht Nutzer in Etappen.

Schneller Rückweg

Ein schlechtes Release in Sekunden zurück.

Sichere Migrationen

Die Datenbank ändert sich ohne Ausfall.

Vertiefung

Releases, so langweilig, dass niemand zuschaut

Das Ziel von Zero-Downtime ist emotional wie technisch: Releases sollen so routiniert sein, dass ein Deploy am Freitagnachmittag keine Augenbraue hebt. Angst vorm Deployen ist die Steuer auf gebündelte Änderungen; nimmt man die Angst, verschwinden die Bündel.

Die Mechanik ist bekannt, Health-geprüfte Rollouts, Connection Draining, rückwärtskompatible Migrationen,, aber die Disziplin steckt in der Reihenfolge: Schema erweitern, Code ausliefern, der beide Formen versteht, Daten migrieren, dann zurückbauen. Ausgelassene Schritte sind die Quelle von Ausfällen.

Rollback wird vor dem Rollout entworfen. Jedes Release weiß, wie es sauber zurücktritt, so wird ein schlechter Deploy vom Vorfall zum Nicht-Ereignis: Der Traffic wechselt zurück, das Team fixt am Montag in Ruhe nach vorn.

Team for AppsProdukt & Entwicklung

Wir bauen Software für Teams, deren Werkzeuge zur tatsächlichen Arbeitsweise passen sollen — Web, Mobile, KI und die Systeme, die alles verbinden. Hier schreiben wir über das, was wir dabei lernen.

Ein Projekt im Kopf?

Erzählen Sie uns, was Sie bauen, und wir melden uns innerhalb eines Werktags.