Fällt eine Story in die letzte «Release-Spalte» vom Kanban Board, bleibt sie nicht lange da. Sie wird so bald wie möglich produktiv gebracht. Sogar unser Kredo: «No deployments on Friday» ignorieren wir immer öfters. Die Vorteile von häufigen und raschen Deployments machen uns glücklich und dich bestimmt auch:
- Ein Feature fängt möglichst schnell damit an Wert zu generieren.
- Die Feedback Loops sind kurz.
- Die Risiken bleiben überschaubar.
Hast du grössere Änderungen zu deployen, empfehle ich vorsichtigere Deployment Methoden anzuwenden. Stressfreie Releases erreichen wir mit Dark-Launche- und Silent Go Life-Techniken.
Continous Delivery: Generiere den Wert so rasch wie möglich
Überschaubare Features mit überschaubaren Auswirkungen werden so bald wie möglich deployed. Unsere Codebasis ist bald 10-jährig und hat auch Legacy Code, welcher eine geringe automatisierte Testabdeckung verfügt. Trotzdem generiert dieser Code erfolgreich Wert. Der Legacy Code wurde identifiziert und in einen Namespace verschoben, welcher Legacy heisst. Durch die Aufteilung vom Code in zwei Namespaces können wir sehr effizient, automatisierte Quality-Checks durchführen mit unterschiedlich strengen Regeln. Neu erzeugter Code oder Teile, die refactored wurden, werden in den zweiten Namespace testbar implementiert. Unit Tests und Code Quality Tests geben uns hier eine Sicherheit. Dafür sorgt unsere Pipeline. Manuell ausgeführte Tests nach Drehbuch ergänzen diese.
Sind die Tests beendet, gelangt das Feature in die Produktion. Ein produktiv Deployment verursacht in der Regel 5-10 Minuten Aufwand.
Das Feedback von Anwendenden kommt so sehr schnell. Sei es positiv, im Sinne von Freude der digitalen Unterstützung oder negativ, wenn ein Feature unerwünschte Nebenwirkungen verursacht. Kein Feedback ist oft auch ein gutes Zeichen und bedeutet meist, dass alles gut läuft.
Das zeitnahe Feedback hilft uns mit dem noch vorhandenen Kontext Wissen, einen aufgetretenen Fehler rasch zu identifizieren und zu beheben.
Dark-Launche-Technik: Halte den Schalter bereit
Grössere Anpassungen haben wir mit einer Dark-Launche Technik stressfrei in die Produktion gebracht.
Die Basis eines Dark-Launche Releases ist ein «Feature-Toggle» Flag, welches die UI Anpassungen, bzw. das Feature sichtbar machen.
Der gesamte Code wurde bereits ins Produktiv System gebracht, bevor die Änderungen für die Benutzenden sichtbar wurden. Teile davon, die lediglich das Backend betreffen wurden aktiviert. So konnten wir allfällige Fehler durch Monitoring bereits aufspüren und eliminieren, bevor operativ jemand davon betroffen war.
Nach ein paar Tagen hat das System bereits viele Daten mit den neuen Features produziert. Die Datenbank konnten wir so in unsere Testumgebung bringen und mit eingeschaltetem Feature die Applikation weiter manuell testen und die Daten auf Korrektheit analysieren. Auf diese Art konnten Nebenwirkungen des Releases bereits weitgehend getestet werden. Nach dem die Tests abgeschlossen waren, haben wir das Feature aktiviert. Prompt hat es trotzdem noch einige kleine Nebenwirkungen verursacht. Dank der Vorbereitungen der Dark-Launche Einstellung, konnten wir die Funktion mit einer Konfiguration in wenigen Minuten wieder «offline» nehmen und die Fehler in aller Ruhe analysieren und nach der Korrektur wieder aktivieren.
Ein komplettes Go Life hätte mit Sicherheit zu Feuerwehrübungen und nächtlichen Heldentaten geführt. Diese werden typischerweise nicht mit Dank gewürdigt, sondern mit frustrierten und genervten Blicken quittiert.
Da alle Systeme mit einer gewissen Lebensdauer von Legacy Code und technischen Schulden betroffen sind, ist potenziell jede Änderung mit Risiken verbunden. Das Risiko haben wir mit der Dark-Launche Technik sehr wirkungsvoll verkleinert, sowie nächtliche Heldentaten durch professionelles Arbeiten ersetzt. Kritische Blicke nach den paar wenigen spürbaren Hick-ups konnten wir so beinahe verhindern.
Canary release: Fange klein und leise an
Unser Kundenportal haben wir komplett überarbeitet. Betroffen davon ist eine grosse Anzahl von Benutzern. Das Kundenportal wird von vielen verschiedenen Firmen aus unterschiedlichen Branchen und Sprachregionen genutzt. Anstatt ein Redirect vom alten Kundenportal zum neuen per Big Bang zu releasen haben wir auf ein Silent Go-Live/Canary Release gesetzt. Zuerst haben wir einige Benutzer gebeten mit unserem neuen Kundenportal, welches noch nirgends verlinkt war zu arbeiten. Der Zugang wurde gezielt zugestellt mit der Bitte, Feedback zu geben. Die Feedbacks konnten wir für Optimierungen nutzen, und danach den Benutzerkreis schrittweise vergrössern.
Als wir das Portal genügend breit gestreut hatten und sicher waren, dass die Kunden damit effizient arbeiten können, wagten wir den Schritt zum Redirect. Den letzten Sprung hat viele gefreut und bei der IT ist nur ein verärgertes Feedback zur Umstellung eingetroffen.
Nun freue ich mich auf einen Kommentar von Dir!
Weiterführende Links:
