gooddeploy
Blog

Wie wir Rollbacks unter einer Sekunde schaffen

Ein Rollback bei gooddeploy baut nichts neu, er schaltet nur um. Wie das funktioniert, was wir gemessen haben und wo die Grenzen der Messung liegen.

Wenn nach einem Release etwas schiefgeht, zählt jede Sekunde: Der Kunde ruft an, das Formular schickt nichts mehr ab, die Startseite zeigt einen Fehler. Dann willst du nicht warten, bis eine alte Version neu gebaut ist. Du willst zurück, sofort.

Bei gooddeploy ist ein Rollback deshalb kein neues Deployment, sondern ein Umschalten. In unserer Messung dauerte es im Median 0,3 Sekunden, bis die vorige Version wieder antwortete.

0,3 sRollback auf die bereite VorversionMedian, 10 Läufe, lokal gemessen
0,5 sdasselbe im 95. Perzentilzugleich der langsamste der 10 Läufe
2,5 sRollback, wenn die Vorversion neu starten mussMedian, ohne Neubau

Das Prinzip: nicht neu bauen, nur umschalten

Jedes Deployment ist bei gooddeploy ein fertiges Image aus genau einem Commit. Was du in der Vorschau geprüft hast, geht unverändert live, und was einmal live war, bleibt als Image erhalten.

  1. DeployImage aus einem Commit, Vorschau-Adresse
  2. Promotedieselbe Version startet auf den Live-Knoten
  3. Umschaltender Proxy zeigt auf die neue Version
  4. VerifyProben gegen die Live-Adresse, bei Fehlern automatisch zurück
  5. RollbackProxy zeigt wieder auf die Vorversion

Drei Dinge machen den Rollback schnell:

  1. Die Vorversion bleibt warm

    Nach einem Promote läuft die vorige Version noch 30 Minuten weiter. In dieser Zeit muss für einen Rollback nichts starten.

  2. Umschalten ist eine einzige Zuordnung

    Der Proxy vor den Apps hält für jede Adresse fest, zu welcher Version sie gehört. Ein Rollback ändert je Adresse und Proxy genau einen Eintrag, ohne den Proxy neu zu laden. Laufende Anfragen an andere Projekte merken davon nichts.

  3. Ohne Neubau auch nach der Warmhaltezeit

    Ist die Vorversion schon gestoppt, startet gooddeploy sie aus dem vorhandenen Image neu. Das dauerte in unserer Messung im Median 2,5 Sekunden, weil nichts gebaut wird; das Image lag dabei schon auf dem Rechner.

$ gooddeploy rollback
→ kunden-shop: zurück auf p2x8d4c1
# Das Datenbank-Schema wird nicht zurückgesetzt.

Was wir gemessen haben

Unser Messwerkzeug spielt den Ablauf so durch, wie du ihn nutzt: mit der CLI, als normaler Nutzer, mit einer Next.js-Beispiel-App mit Postgres. Je Kennzahl gab es 10 Läufe.

Zeit bis zur ersten Antwort der ZielversionBalkendiagramm. Rollback, Vorversion bereit: Median (P50) 0,3 s, 95. Perzentil (P95) 0,5 s; Rollback, Vorversion startet neu: Median (P50) 2,5 s, 95. Perzentil (P95) 3,8 s; Live schalten (promote): Median (P50) 2,2 s, 95. Perzentil (P95) 2,8 s; Umgebungsvariable ändern: Median (P50) 4,3 s, 95. Perzentil (P95) 5 s.Median (P50)95. Perzentil (P95)Rollback, Vorversion bereit0,3 s0,5 sRollback, Vorversion startet neu2,5 s3,8 sLive schalten (promote)2,2 s2,8 sUmgebungsvariable ändern4,3 s5 s
Zeit bis zur ersten Antwort der Zielversion je 10 Läufe am 18. Oktober 2026, lokal auf einem Rechner
Werte als Tabelle
Median (P50)95. Perzentil (P95)
Rollback, Vorversion bereit0,3 s0,5 s
Rollback, Vorversion startet neu2,5 s3,8 s
Live schalten (promote)2,2 s2,8 s
Umgebungsvariable ändern4,3 s5 s

Die einzelnen Läufe zeigen, wie gleichmäßig die Werte sind:

Rollback je LaufLiniendiagramm über 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. Vorversion bereit: 0,4; 0,3; 0,3; 0,3; 0,4; 0,3; 0,3; 0,5; 0,5; 0,4 · Vorversion startet neu: 3,2; 3,2; 3,1; 2; 3; 1,9; 1,9; 3,8; 2,5; 2,3.Vorversion bereitVorversion startet neu0 s1,25 s2,5 s3,75 s5 s12345678910
Rollback je Lauf Lauf 1 bis 10, lokal am 18. Oktober 2026
Werte als Tabelle
12345678910
Vorversion bereit0,4 s0,3 s0,3 s0,3 s0,4 s0,3 s0,3 s0,5 s0,5 s0,4 s
Vorversion startet neu3,2 s3,2 s3,1 s2 s3 s1,9 s1,9 s3,8 s2,5 s2,3 s

So haben wir gemessen

  1. Uhr startet mit dem Befehl

    Gemessen wird die Wanduhr vom Start von gooddeploy rollback bis zur ersten erfolgreichen Antwort der Zielversion.

  2. Antwort über den Proxy

    Alle 100 Millisekunden fragt das Messwerkzeug die Live-Adresse ab. Gezählt wird erst, wenn die Antwort die Kennung der Zielversion trägt.

  3. Warm und kalt getrennt

    „Bereit“ heißt: Die Vorversion läuft noch. „Startet neu“ heißt: Wir haben ihre Container vorher entfernt, wie nach der Warmhaltezeit. Das Image lag lokal vor, ein Download aus einer entfernten Registry ist nicht enthalten.

Und die Datenbank?

Ein Rollback tauscht die App, nicht die Daten. Hat die neue Version das Schema geändert, läuft die alte Version danach gegen das neue Schema. Darum gilt: Migrationen so schreiben, dass die vorige Version damit noch zurechtkommt, also Spalten erst hinzufügen und erst in einem späteren Release entfernen.

Platzhalter

Hier steht später eine Stimme aus dem Pilot, zum Beispiel, wie sich ein Rollback im Alltag einer Agentur anfühlt.

— Pilotagentur (Platzhalter)

Häufige Fragen

Gilt die Sekunde auch auf der Plattform?

Unsere Werte stammen aus einer lokalen Messung ohne Netzwerkwege. Auf der Plattform kommen Netzwerk und Zertifikat dazu; die Messung mit Next.js auf der Plattform steht noch aus.

Wie lange kann ich auf eine Vorversion zurück?

Die Vorversion bleibt als Image erhalten. In den ersten 30 Minuten nach einem Promote läuft sie noch, danach startet gooddeploy sie für einen Rollback ohne Neubau neu.

← Alle Artikel