Der Ablauf
- Die neue Fassung wird gebaut, während die alte weiterläuft.
- Sie wird gestartet – aber noch bekommt sie keinen Verkehr.
- Ein Gesundheitscheck fragt sie, ob sie bereit ist.
- Erst wenn sie antwortet, leitet der Proxy neue Anfragen dorthin.
- Die alte Fassung bearbeitet laufende Anfragen zu Ende und wird dann gestoppt.
Scheitert Schritt drei, passiert nichts: Die alte Fassung läuft weiter, das Deployment gilt als fehlgeschlagen. Genau das ist der Gewinn – ein kaputter Build nimmt die Seite nicht mit.
Was du dafür tun musst
- Ein ehrlicher Gesundheitscheck. Ein Pfad, der erst „OK“ sagt, wenn die Anwendung wirklich arbeiten kann – inklusive Datenbankverbindung. Ein
/health, das immer 200 zurückgibt, macht den ganzen Ablauf wertlos. - Abwärtskompatible Datenbankänderungen. Für einen Moment laufen alte und neue Fassung gleichzeitig auf derselben Datenbank. Eine Spalte, die die alte Fassung noch braucht, darf nicht im selben Schritt verschwinden.
- Sauberes Beenden. Die Anwendung soll auf das Stopp-Signal reagieren, laufende Anfragen zu Ende bringen und dann gehen, statt sofort abzubrechen.
Wie es bei Branchway läuft
Der Ablauf oben ist das Standardverhalten, nicht eine Einstellung: Jedes Deployment startet die neue Fassung parallel, prüft sie und schaltet erst dann um. Den Pfad und die Schwellen des Gesundheitschecks stellst du je App ein.
Geht nach dem Umschalten doch etwas schief, kommst du mit einem Klick auf die vorige Fassung zurück – sie ist noch vorhanden und muss nicht neu gebaut werden.
Häufige Fragen
Brauche ich dafür mehrere Instanzen?
Nein. Auch bei einer Instanz läuft die alte Fassung weiter, bis die neue bereit ist – die beiden überlappen sich kurz.
Was ist mit langen Hintergrundaufgaben?
Die sollten abbruchsicher sein: Wird ein Arbeitsprozess gestoppt, muss die Aufgabe später erneut laufen können, ohne Schaden anzurichten.