Rollbacks von Deployments sind von gestern

Rollbacks im Deployment-Kontext bedeutet Änderungen "rückgängig zu machen", in dem einfach wieder die alte Version eingespielt wird.

Doch das ist lange nicht mehr zeitgemäß. Warum das eine schlechte Idee ist, will ich heute etwas näher eingehen.

Was macht Rollbacks so sympathisch?

Klingt erst mal super: Was kaputt ist, davon hol ich die Version von vorher, alles wieder super! Doch das ist nicht immer so einfach, denn das bedeutet man muss alte Versionen entsprechend lange aufbewahren. Prozesse hierzu sind meistens alles andere als einfach oder unkompliziert.

Doch finden sie gerade bei alten Monolithen Verwendung, dort macht es meistens auch Sinn da viele Änderungen auf einmal auf eine neue Stage überführt werden. Entsprechend ist das Potenzial eines Totalversagens deutlich wahrscheinlicher.

Klingt gut, warum ist es blöd?

Für Monolithen ist das eine super Sache, doch wir wollen ja - weg von fetten Brocken - hin zu vielen Kleinen.

MVC - nicht zu verwechseln mit dem Model View Controller-Pattern - wird von Gitlab als große Lösung gefeiert. "Minimum Valuable Change". Also wir deployen einfach ganz oft, und dafür in kleinen Stückchen, die auch Sinn ergeben. Klappt nicht? Kein Problem, der Fix ist nicht groß weil das Feature überschaubar ist.

Never look back ist hier das Motto. Das macht es deutlich einfacher, keine komplizierten Rollbacks und Versionskonfusion, der Stand in Git entspricht dem aktiv deployten Stand.

Vorteile

Die Vorteile sind klar: Man spart sich komplexe Prozesse, eine Menge Geld und Gehirnzellen bei dem Ausdenken einer passenden Strategie für die Anwendung(en).

Dadurch, dass man eben nicht alles zurückrollen kann, kommt man gar nicht auf die Idee so große Pakete zu schnüren. Denn niemand hat Lust das Ganze zu fixen. In Folge verbessert es also die Frequenz von Deployments.

Ohne das große Sicherheitsnetz wird man automatisch sensibler für Änderungen. Will man wirklich so viel auf einmal live geben? Nicht lieber langsam etwas freigeben? Vielleicht doch lieber einen Test mehr schreiben?

Nachteile

Natürlich kann es auch sein, dass sich ein Problem einfach nicht lösen lässt, der Bug ist zu hartnäckig. Doch wir deployen ja jeden Change (wenn man brav squasht - einen Commit) und der lässt sich mit Git super einfach reverten. Dadurch wird in der Historie klar, wann etwas nicht funktioniert hat. So bleibt die Struktur klar und man kann Deployment- und Git-History fließend kombinieren.

Das erfordert natürlich ein Umdenken und sorgt am Anfang öfter für Probleme. Kein Rollback?! - Bist du wahnsinnig?!

Natürlich steigt dadurch das Risiko, dass Production eine kurze Zeit nicht oder nicht vollständig funktioniert, wie es soll. Das ist ein kalkulierbares Risiko, welches aber in der Regel durch den damit einhergehenden Wettbewerbsvorteil immer geringer wird.

Mein Fazit

Ich nutze Rollbacks so gut wie nie und gehe lieber den Weg der kleinsten Veränderung, die Sinn macht. In der Praxis klappt das super und macht weniger Probleme als fette Feature-Releases. Oder klassisches: "Wir deployen immer am 3. Freitag wenn die Katze sich an den Pfoten leckt".

Natürlich kann man bei fehlgeschlagenen Deployments zurückrollen, wenn die Anwendung zum Beispiel gar nicht hochfährt. Das sollte aber nur ein Notfallmechanismus sein und direkt vom Deployment-Controller abgehandelt werden. Sobald hier eigene Logik gebaut werden muss, sollte man diesen wechseln oder sich fragen ob das wirklich Sinn macht.