Continuous Integration / Continuous Delivery: Production Release und abschließende Gedanken

Dieser Blogbeitrag ist Teil einer vierteiligen Serie, die Einblicke in unsere Continuous Integration / Continuous Delivery-Prozesse (CI/CD-Prozesse) gibt, die für ein schnell wachsendes Monorepo mit mehreren Anwendungen verwendet werden:

• Teil 1: CI/CD: Einführung
• Teil 2: CI/CD: Vom lokalen Quellcode zum Pull-Request
• Teil 3: CI/CD: Vom Pull-Request zu Testumgebungen
• Teil 4: CI/CD: Veröffentlichung in Produktion und abschließende Gedanken (dieser Artikel)

Releases

Bei Peaks & Pies führen wir „Push-Button“-Releases durch, was bedeutet, dass jedes Production Deployment manuell initiiert werden muss. Folglich praktizieren wir kein Continuous Deployment, sondern Continuous Delivery. Releases erfolgen in der Regel mehrmals wöchentlich und werden je nach Bedarf ausgerollt. Da unser Main Branch während seines gesamten Lebenszyklus deployable bleibt, kann jeder Entwickler jederzeit einen Release starten. Der vollständig automatisierte Release Prozess wird über unser GitHub Repository gestartet und löst die Production Pipeline aus.

Ausführung der Production Pipeline

Die erforderlichen Schritte zur Erstellung des Production Builds sind fast identisch mit denen der Staging Pipeline:

• Installation von Dependencies: Dependencies aller Apps und Packages werden installiert.
• Ausführung der Test-Suite: Unit-Tests für das gesamte Repository werden automatisch ausgeführt.
• Build der Apps: Jede App wird gebaut. Dies umfasst weitere Prüfungen wie Type Checking und Linting.
• Erstellen von Docker Images: Basierend auf dem offiziellen Node Image (alle unsere Apps sind NextJS Apps).
• Push der Docker Images in die Artifact Registry: Die neu erstellten Docker Images werden in die Artifact Registry in Google Cloud gepusht.
• Deployment von Revisionen mit Tag: Jedes Docker Image erhält einen Tag, der indiziert, dass es sich um ein Production Build handelt, und wird über Cloud Run deployed.

Es gibt hierzu eine Ausnahme: Bei einer unserer Apps handelt es sich um ein Headless Content Management System (CMS), das von uns verwaltet und erstellt wird, aber nicht über Cloud Run deployed wird. Mithilfe des CLI des CMS-Anbieters deployen wir die Produktionsversion der App auf deren Plattform. Dieser Schritt wird ebenfalls von der Production Pipeline übernommen.

Geschafft!

Continuous Delivery ist somit erreicht und ein weiterer Production Release ist veröffentlicht! Releases samt kurzem Changelog werden auf Slack gepostet, um das Team zu informieren. Wenn in dieser Phase doch noch etwas kaputt geht, haben wir die Möglichkeit, sofort den gesamten Traffic auf die letzte korrekt funktionierende Container Revision umzuleiten und uns sofort um die Bugs zu kümmern. Zu dieser Maßnahme müssen wir aber äußerst selten greifen.

Testing in Production

In Ausnahmefällen sind nach einem Release weitere Maßnahmen erforderlich. Testing in Production (TIP) ist eine Methode in der Softwareentwicklung, mit der neue Code Änderungen auf Live-Benutzerdaten getestet werden, anstatt in einer sicheren, nicht-öffentlichen Umgebung. Diese Methode ist in seltenen Fällen unvermeidbar. Bei Peaks & Pies hatten wir kürzlich zwei Situationen, in denen wir keine andere Wahl hatten, als TIP zu nutzen. Einmal war es das Testen eines Cookies, das wir für einen Kunden setzen mussten und das nur auf einer Subdomain dieses Kunden getestet werden konnte. Der zweite Fall war ein Webmodul von signifikanter Bedeutung, das stark von der API eines Kunden abhängt. Hierfür haben wir eine separate Revision deployed und nur einen sehr begrenzten Teil des Traffics auf dieses Modul umgeleitet. Sobald sich zehn Besucher durch die Funktionalitäten geklickt hatten, haben wir die Revision sofort wieder heruntergefahren, um die Ergebnisse auszuwerten. Während es sich für Peaks & Pies bei diesen Fällen um Ausnahmen handelt, kann TIP durchaus nützlich sein und wird heutzutage häufig verwendet, um schnelles Feedback zu erhalten.

Abschließende Gedanken

Durch ausgeklügelte Continuous Delivery Prozesse werden Deployments zu vorhersehbaren Routine Angelegenheiten. Infolgedessen deployen wir häufig und verzeichnen positive Trends bezüglich folgender Metriken:

• Wahrscheinlichkeit unerwünschter Nebeneffekte: Häufige Deployments und Testing führen zu inkrementeller Entwicklung der Software und senken somit die Wahrscheinlichkeit von Bugs und Fehlern drastisch.
• Schadensausmaß eventueller Fehlern: Durch häufige Integration und Deployment von überschaubaren Code Änderungen sind Bugs in der Regel von geringem Ausmaß.
• Zeit zur Fehlererkennung und -behebung: Kleinere Fehler führen zu einfachen und schnellen Fehlerbehebungen.

Hauptvorteile

• Reduziertes Entwicklungsrisiko: Deployment kleinerer Änderungen bedeutet, dass weniger schief gehen kann. Einfachere Korrekturen führen zu reibungslosen Releases.
• User- und Design-Feedback: Früheres Feedback im Prozess (das größte Risiko eines Softwareprojekts ist, dass man am Ende etwas baut, das nicht nützlich ist).
• Glaubwürdiger Fortschritt: Der „Done“-Status der Arbeit eines Entwicklers ist in einer produktionsähnlichen Umgebung sichtbar, nicht nur in Form eines abgeschlossenen Tickets.
• Glücklicheres Team: Entwickler können sich aktiver mit Usern, Produkt und Designern auseinandersetzen und lernen aus erster Hand über die Ergebnisse ihrer Arbeit.

Quo vadis?

Während des Schreibens dieser Beitragsserie haben wir intern mehrere Bereiche mit Verbesserungspotenzial identifiziert, die wir in Zukunft angehen möchten. Wir haben in der Zwischenzeit bereits unsere Dokumentation verbessert, die interne Reihenfolge unserer Pipelines geändert und priorisieren nun das Ausführen der Test Suite für schnelleres Feedback.

Weitere Bereiche, die wir genauer untersuchen möchten:

• Verschieben von Assets und statischen Dateien in ein Content Delivery Network (derzeit im Docker Image enthalten, was keine gute Praxis ist).
• Überprüfung des Pipeline Designs: Hinzufügen von Logik, um nur Apps neu zu erstellen, die tatsächlich geändert wurden, Implementierung von Caching und Verschachteln von Docker Images.
• Zusätzliche automatisierte Tests (z.B. Chromatic für unsere Storybook Instanz).
• Pipelines für die Storybook Instanz haben Verbesserungsbedarf (wir spielen mit dem Gedanken, die Staging Pipeline komplett zu entfernen).
• Automatisierte Bereinigung nicht (mehr) verwendeter Images in der Artifact Registry.
• Optimierungspotenzial des Release Prozesses durch intelligente Nutzung von Environment Variables.
• Konzepte und Abläufe erstellen, die früheres erstes Feedback zum Code ermöglichen (z.B. Pair Programming), damit Pull Request Reviews einfacher und besser portionierbar werden.