Deploy ist ein kritischer Schritt im SAFe for DevOps Health Radar. Nachdem wir ein deploybare Paket erstellt und es in einer Staging-Umgebung getestet haben, wollen wir nun unsere Änderungen kontinuierlich in die Produktionsumgebung deployen. Das Ziel ist es, mit hoher Frequenz und niedrigem Risiko zu deployen. In diesem Video erkläre ich, wie wir das erreichen und welche Praktiken Continuous Deployment ermöglichen.
Die bisherige Reise#
Bevor wir den Deploy-Schritt erreichen, haben wir bereits mehrere Schritte im SAFe DevOps Health Radar durchlaufen. Alles begann mit einer Hypothese, in der wir gute Ideen in Epic-Form erfasst haben. Dann haben wir kollaboriert und recherchiert, um Kunden- und Marktbedürfnisse zu verstehen. Im Architect-Schritt haben wir die minimale Architektur entworfen, um unsere Hypothese zu beweisen. Wir haben synthetisiert, indem wir das Epic in Features für das Program Backlog heruntergebrochen haben. Im Develop-Schritt haben wir das Feature durch Aufteilen in User Stories codiert. Wir haben den Code committet und ein deploybare Paket gebaut. Danach haben wir das Paket in eine Staging-Umgebung für End-to-End-Tests deployed.
Jetzt, im Deploy-Schritt, bringen wir unsere Änderungen in die Produktionsumgebung.
Warum Continuous Deployment?#
Der Grund, warum wir unsere Änderungen kontinuierlich in die Produktion deployen wollen, ist einfach: Kleine Änderungen bergen ein geringeres Risiko als grosse Änderungen. Wenn wir kleine Änderungen häufig deployen, hat jedes Deployment eine geringere Wahrscheinlichkeit zu scheitern. Wenn sich hingegen Änderungen über drei Monate ansammeln, wird das Deployment viel grösser und das Risiko steigt erheblich.
Continuous Deployment bedeutet: Mit hoher Frequenz und niedrigem Risiko in das Produktionssystem deployen.
Deployment von Release trennen#
Um kontinuierlich in die Produktion deployen zu können, müssen wir Deployment von Release trennen. Ein Deployment bringt den kompilierten Code in die Produktion mit dem Feature Switch ausgeschaltet. Ein Release schaltet den Feature Switch in der Produktionsumgebung ein.
Diese Unterscheidung ist grundlegend. Wir haben dieses Konzept bereits im Architect-Schritt besprochen, denn es ist wichtig, Systeme von Anfang an so zu architekturieren, dass Deployment und Release getrennt werden können.
Feature Toggles#
Feature Toggles (auch Feature Switches genannt) ermöglichen es uns, Features ein- und auszuschalten. Im Kern ist ein Feature Toggle nichts anderes als eine If-Anweisung. Wenn das Flag gesetzt ist, ist das neue Verhalten aktiv. Wenn das Flag nicht gesetzt ist, bleibt das alte Verhalten bestehen.
Es gibt wichtige Regeln beim Umgang mit Feature Toggles:
- Jeder Toggle erzeugt einen Testfall. Mehrere Feature Toggles erzeugen eine kombinatorische Explosion von Szenarien, die getestet werden müssen.
- Toggles nach dem Release entfernen. Ein Feature Toggle ist temporär. Sobald das Feature released und stabil ist, muss der Toggle aus dem Code entfernt werden.
- Toggles nicht mit Applikationskonfiguration verwechseln. Applikationskonfiguration ist langlebig und ermöglicht die Konfiguration des Applikationsverhaltens. Ein Feature Toggle ist kurzlebig und existiert nur, um Continuous Deployment zu ermöglichen.
Dark Launches#
Die Trennung von Deployment und Release sowie der Einsatz von Feature Toggles ermöglichen Dark Launches. Bei einem Dark Launch deployen wir neuen Code in die Produktion mit dem Feature Toggle ausgeschaltet. Das erlaubt uns, Monitoring und Alerting in der Produktionsumgebung zu testen. Wir können beobachten, wie sich der neu deployed Code mit echten Produktionsdaten verhält, ganz ohne Auswirkungen auf die Endbenutzer.
Versionskontrolle für alles#
Wenn wir kontinuierlich in die Produktion deployen wollen, müssen wir alles in der Versionskontrolle haben. Nicht nur den Code, sondern auch die Infrastrukturkonfiguration, Testdaten, Anforderungen und Architekturdokumentation. Alles in der Versionskontrolle zu haben ermöglicht schnelle Rollbacks und eine rasche Untersuchung von Produktionsproblemen, da wir genau wissen, was deployed wurde und was sich gegenüber der vorherigen Version geändert hat.
Infrastructure as Code#
Infrastructure as Code ermöglicht ein automatisiertes Umgebungs-Setup. Wir definieren, wie unsere Infrastruktur aussehen soll, in Konfigurationsdateien, und diese Konfigurationsdateien werden in der Versionskontrolle gespeichert. Mit Tools wie Chef, Puppet und anderen können wir unsere Infrastruktur automatisch provisionieren und konfigurieren. Dieser Ansatz spart Kosten, erhöht die Geschwindigkeit und senkt das Risiko, da das Infrastruktur-Setup jedes Mal konsistent und wiederholbar ist.
Deployment-Automatisierung#
Um kontinuierlich in die Produktion zu deployen, müssen wir alle Schritte automatisieren, die nötig sind, um kompilierten Code in die Produktion zu bringen. Das ist die Deployment-Automatisierung. Es ist wichtig, dass Entwickler immer Feedback erhalten, ob ein Deployment erfolgreich war oder fehlgeschlagen ist.
Wenn vollständige Automatisierung nicht erlaubt ist (zum Beispiel in regulierten Umgebungen mit Anforderungen an die Funktionstrennung), können wir Self-Service Deployment einsetzen. Dies wird auch als Push-the-Button Deployment bezeichnet. Der Deployment-Prozess ist weiterhin vollständig automatisiert, aber eine Person löst ihn durch Knopfdruck aus.
Selektive Deployments#
Selektive Deployments geben uns Flexibilität beim Releasing. Mit selektiven Deployments können wir in eine einzelne geografische Region, ein einzelnes Rechenzentrum, einen Server-Cluster oder ein Netzwerksegment deployen. Das senkt das Risiko und ermöglicht flexiblere Releases.
Blue-Green Deployments#
Blue-Green Deployments sind eine weitere leistungsstarke Praktik für Deployments. Wir unterhalten zwei identische Produktionsumgebungen: eine ist live (grün) und eine ist inaktiv (blau). Alle Benutzer arbeiten auf der Live-Umgebung. Währenddessen deployen wir die nächste Version in die inaktive Umgebung.
Sobald das Deployment in die inaktive Umgebung abgeschlossen ist, können wir die neue Version dort testen, ohne Benutzer zu beeinträchtigen. Wenn alles gut aussieht, schalten wir den Load Balancer um, sodass die blaue Umgebung live wird und die grüne Umgebung inaktiv. Falls etwas schiefgeht, können wir schnell zur vorherigen Version zurückwechseln.
Blue-Green Deployments haben Kompromisse. Man benötigt zwei vollständige Produktionsumgebungen, was die Kosten erhöht. Der Ansatz ist unkompliziert für zustandslose Anwendungen, wird aber komplexer, wenn Datenbanken oder andere zustandsbehaftete Komponenten beteiligt sind. Das erfordert sorgfältige Architektur und Design.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Deploy-Schritt:
- Sit: Features werden alle drei oder mehr Monate in die Produktion deployed. Deployments sind manuell und schmerzhaft. Deployed bedeutet gleichzeitig released.
- Crawl: Features werden am PI-Boundary (Dreimonatszyklus) in die Produktion deployed. Deployments sind grösstenteils manuell. Deployed bedeutet gleichzeitig released.
- Walk: Features werden jede Iteration in die Produktion deployed. Deployments sind grösstenteils automatisiert. Einige Features können deployed werden, ohne released zu werden.
- Run: Features werden jede Iteration vollständig automatisiert durch die Pipeline in die Produktion deployed. Dark Releases sind üblich.
- Fly: Features werden kontinuierlich während jeder Iteration deployed. Entwicklungsteams initiieren Deployments direkt über Pipeline-Tools. Release ist vollständig vom Deployment entkoppelt. Dark Releases sind die Norm.
Kernaussagen#
- Mit hoher Frequenz und niedrigem Risiko deployen. Kleine, häufige Deployments sind sicherer als grosse, seltene.
- Deployment von Release trennen. Deployment bringt Code in die Produktion mit dem Feature Toggle ausgeschaltet. Release schaltet den Feature Toggle ein.
- Feature Toggles klug einsetzen. Sie ermöglichen Continuous Deployment, aber denken Sie daran, sie nach dem Release des Features zu entfernen.
- Dark Launches nutzen. In die Produktion deployen, ohne für Benutzer freizugeben, um den neuen Code zu überwachen und zu validieren.
- Alles automatisieren. Von der Infrastruktur bis zum Deployment ist Automatisierung die Grundlage von Continuous Deployment.
- Blue-Green Deployments in Betracht ziehen. Sie ermöglichen Deployments ohne Ausfallzeit und schnelles Rollback, erfordern aber sorgfältige Planung für zustandsbehaftete Komponenten.