Continuous Integration / Continuous Delivery: Einführung

CI/CD steht für Continuous Integration / Continuous Delivery (in seltenen Fällen auch Continuous Deployment, Erklärung in der Fußnote1). Es handelt sich dabei um eine Methode in der Softwareentwicklung, bei der Software so gebaut wird, dass sie jederzeit für die Produktion freigegeben werden kann.

Die Hauptidee besteht darin, häufige Builds zu erzeugen, um frühzeitig im Entwicklungsprozess Feedback zu erhalten und Änderungen zu erkennen, die später unerwünschtes Verhalten verursachen könnten, wie z. B. Leistungs-, Sicherheits- oder Usability-Probleme. Durch die Umsetzung von CI/CD werden sichere, schnelle und stressfreie Production Releases ermöglicht.

Diese Blogreihe wird in vier Teilen veröffentlicht und bietet Einblicke in unseren CD-Prozess, der für ein schnell wachsendes Monorepo mit mehreren Anwendungen verwendet wird:

• Teil 1: CI/CD: Einführung (dieser Artikel)
• 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 die Produktion und Schlussgedanken

CI/CD Pipeline

Der zentrale Teil dieser Praxis ist die CI/CD Pipeline, die alle erforderlichen Schritte definiert, um unsere Software zu bauen, zu testen und bereitzustellen, d. h. wie wir vom Source Code Management (SCM) zur Produktionsfreigabe gelangen. Sie fördert die Zusammenarbeit zwischen den verschiedenen Teams, die an der Softwarebereitstellung beteiligt sind, und bietet Transparenz über den Änderungsverlauf sowie einen genauen Audit-Trail. Auf diese Weise wird der Großteil möglicher Probleme frühestmöglich im Entwicklungsprozess erkannt, oft bereits auf dem lokalen Rechner der Entwickler. In fortgeschritteneren Phasen der Entwicklung, bspw. nach der Zusammenführung mehrerer Änderungen, werden dann zeitintensivere, detaillierte Checks mit manuellen Überprüfungen kombiniert.

Das folgende Diagramm zeigt eine vereinfachte Darstellung dieses Prozesses, wie er bei Peaks & Pies derzeit praktiziert wird. Weitere Details zu den einzelnen Phasen und deren Eigenschaften werden in den kommenden Blogbeiträgen genauer beleuchtet.

Source Code Management

Die Arbeit an einem sich ständig weiterentwickelnden Projekt mit zehn involvierten Entwicklern kann schnell chaotisch werden. Deshalb integrieren wir die neuesten Best Practices für Zusammenarbeit und Sicherheitsstandards. Darüber hinaus wird der Quellcode kontinuierlich analysiert und bereits früh im Prozess überprüft, idealerweise schon auf den lokalen PCs unserer Entwickler.

Remote-SCM spielt eine entscheidende Rolle, wenn es darum geht, diese Änderungen zusammenzuführen und mit Teammitgliedern für manuelle Code-Reviews oder zur Zusammenarbeit zu teilen. Das Remote-SCM fungiert hierbei als Gatekeeper mit der Verantwortung, direkte Code-Commits zum Main Branch und Production Deployments zu blockieren. Zu den weiteren Aufgaben des Remote-SCM zählen die Durchführung von Qualitätsprüfungen und das Auslösen automatisierter Prozesse. Die Kommunikation zwischen Remote-SCM und der CI/CD Plattform ist hierbei von entscheidender Bedeutung.

CI/CD Plattform

Eine CI/CD Plattform ist eine Anwendung, die für die Ausführung der in der CI/CD Pipeline definierten Schritte verantwortlich ist. Unser Team verwendet Cloud Build, eine serverless CI/CD Plattform, die von Google angeboten wird. Andere etablierte Anbieter ähnlicher Dienste sind GitHub Actions, Jenkins oder GitLab. Durch die nahtlose Integration in unser GitHub Repository wartet Cloud Build auf Änderungen im Quellcode und setzt vordefinierte automatisierte Prozesse in Gang, sobald ein Trigger betätigt wird.

Der CI-Prozess umfasst das Zusammenführen, Bauen und Testen des Codes in Entwicklungsumgebungen und ermöglicht somit regelmäßige Merges in unseren Main Branch. Auf diese Weise kann vermieden werden, dass eine unübersichtliche Anzahl von Codeänderungen auf einmal integriert werden muss.

Nach erfolgreichem Abschluss des CI-Prozesses übernimmt der CD-Prozess, verpackt und stellt die Anwendung in einer Test- und/oder Staging-Umgebung bereit, wo weitere Prüfungen wie Integrations- oder E2E-Tests durchgeführt werden können. Dieser Schritt testet somit auch direkt den Deployment Prozess der Apps, welcher ein kritischer Bestandteil für zuverlässige Releases von Software ist.

Production Deployment

Nach reibungslosem Durchlaufen der automatisierten Pipeline ist alles bereit für einen manuellen Production Release. Generell können Teams individuell entscheiden, wie und wann freigegeben wird, je nach Business Requirements, manuellen Genehmigungsprozessen oder anderen Einschränkungen.

CI/CD Prinzipien von Peaks & Pies

Bei Peaks & Pies konzentrieren wir uns auf die folgenden Schlüsselprinzipien bei der Ausübung von CI/CD:

• Schnelle Builds, um schnelles Feedback zu erhalten
• Unterteilen des Production Builds in Phasen, wobei mit jeder Phase schrittweise zunehmende Sicherheit gewährleistet wird
• Der Stand des Main Branches ist jederzeit bereit für ein Deployment, was dazu führt, dass Deployments zu einer vorhersehbaren Routine Angelegenheit werden

Wie Peaks & Pies diese Methoden in der Praxis umsetzt, wird im nächsten Blogbeitrag genauer erläutert.

1) Der Begriff Continuous Deployment wird manchmal anstelle von Continuous Delivery verwendet. Continuous Deployment umfasst alle Aspekte von Continuous Delivery mit der zusätzlichen Bedingung, dass jede Codeänderung, die alle Phasen der Pipeline erfolgreich durchläuft, ohne manuelle Eingriffe in Produktion bereitgestellt wird. In diesem Fall gibt es keine abschließende manuelle Qualitätssicherung. Bei Peaks & Pies praktizieren wir Continuous Delivery: Unsere Software bleibt während ihres gesamten Lebenszyklus bereitstellbar, aber wir bevorzugen es, manuelle Production Releases zu tätigen.