Wenn ich ein neues Team betrete und wissen will, wie reif der Umgang mit Deployments ist, stelle ich nicht die Frage, wie schnell sie ausliefern können. Ich frage, wie schnell sie zurückkönnen. Die Antwort auf diese zweite Frage sagt mir alles über den Ernst, mit dem hier gearbeitet wird.
Ein Release nach vorn zu bringen ist die halbe Arbeit, oft sogar die einfachere. Der Code ist getestet, alle sind gespannt, es gibt Aufmerksamkeit. Der Rollback dagegen ist der Moment, in dem etwas brennt, alle nervös sind und niemand mehr klar denkt. Genau deshalb darf der Rollback nicht der Teil sein, den wir dem Zufall überlassen. Er muss der eingeübte, langweilige, verlässliche Teil sein.
Ich habe mir angewöhnt, jeden Deploy-Weg von hinten zu denken. Bevor ich überlege, wie die neue Version live geht, überlege ich, wie ich sie in unter fünf Minuten wieder loswerde, ohne nachzudenken. Wenn ich diese Frage nicht klar beantworten kann, ist das Deployment nicht fertig, egal wie schön die Pipeline aussieht. Ein Release ohne geübten Rückweg ist ein Sprung ohne zu wissen, ob unten Wasser ist.
Automatisierung hilft hier enorm, aber nur, wenn ich ihr wirklich vertraue. Und Vertrauen entsteht nicht durch das Skript, sondern durch Wiederholung. Deshalb übe ich Rollbacks bewusst, auch wenn nichts kaputt ist. Wir spielen es durch, in einem ruhigen Moment, ohne Druck. Wenn der Ernstfall kommt, ist es dann kein Experiment mehr, sondern ein Handgriff, den alle kennen.
Ein zweiter Punkt, der oft vergessen wird: Der Rollback der Anwendung ist einfach, der Rollback der Daten ist es fast nie. Eine Migration, die Spalten löscht, macht den Rückweg unmöglich. Deshalb baue ich Änderungen an der Datenbank so, dass alte und neue Version eine Weile nebeneinander leben können. Erst wird die neue Spalte hinzugefügt, dann läuft der Code, und erst viel später, wenn ich sicher bin, wird Altes entfernt. Diese Trennung nimmt dem Deployment seinen Schrecken.
Schnelligkeit beim Ausliefern beeindruckt in der Präsentation. Ruhe im Ernstfall entscheidet über den Schlaf des Teams. Ich baue lieber für die Ruhe.
– Sergey Shinder
