Continuous Integration / Continuous Delivery: Vom Pull Request zu Testumgebungen

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

• 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 (dieser Artikel)
• Teil 4: CI/CD: Veröffentlichung in die Produktion und abschließende Gedanken

Erster Trigger für die CI/CD-Plattform: Erstellung eines Pull Requests

In unserem CI/CD-Prozess löst die Erstellung eines Pull Requests auf GitHub einen ersten Trigger aus. Dies geschieht durch eine Cloud Build Anwendung, die in unser GitHub Repository integriert ist und den Code ständig nach Änderungen scannt. Der CI/CD-Plattform wird auf diese Weise mitgeteilt, dass die Preview Pipeline ausgeführt werden kann. Ihr Ziel ist es, alle Anwendungen in einer sicheren Preview Umgebung bereitzustellen und nur die Änderungen des spezifischen Pull Requests zu widerspiegeln. Die daraus resultierenden Preview Links ermöglichen es Entwicklern, Designern und Consultants, manuelle Qualitätsprüfungen in einer isolierten Umgebung durchzuführen. Darüber hinaus können die Links mit anderen Stakeholdern oder dem Kunden selbst geteilt werden.

Ausführung der Preview Pipeline

Sobald die CI/CD-Plattform über den Pull Request informiert ist, beginnt sie, eine Reihe von vordefinierten Schritten für die Preview Pipeline auszuführen. Die Anweisungen, welche Schritte in welcher Reihenfolge ausgeführt werden sollen, sind in unserem Code in einer separaten .yaml-Datei definiert. Diese Datei wird von der Cloud Build App erkannt und ausgeführt. Während der Ausführung der Pipeline sendet Cloud Build regelmäßig Statusberichte an GitHub zurück, die erfolgreiche Schritte oder fehlgeschlagene Prozesse anzeigen. Solche Statusberichte können im jeweiligen Pull Request eingesehen werden und enthalten Links zu detaillierten Logs auf Google Cloud, welche den Entwicklern zur weiteren Fehlersuche dienen.

CI-Prozess

Der CI-Teil der Pipeline konzentriert sich hauptsächlich auf die Durchführung automatisierter Prüfungen und Tests des Quellcodes, bevor anschließend die Applikationen gebaut werden. Da unser Monorepo mehrere Apps enthält, werden die meisten Schritte parallel für jede davon durchlaufen:

• Installation von Dependencies: Die 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.

CD-Prozess

Nach erfolgreichen Builds aller Anwendungen ist der CD-Teil der Pipeline für das Packaging und Deployment des Codes verantwortlich. Dies umfasst die folgenden Schritte, welche erneut parallel für jede App durchgeführt werden:

• 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 sich auf den Pull Request bezieht und wird über Cloud Run deployed.
• Verlinken der Revisionen im Pull Request: Die URL der erfolgreich bereitgestellten Revision wird im Pull Request auf GitHub vermerkt.

Merge des Pull Requests in den Main Branch

Nach dem Deployment der voll funktionsfähigen Apps in der Preview Umgebung stehen erste manuelle Prüfungen an:

• Der Entwickler überprüft seine eigene Arbeit erneut.
• Je nach Änderungen weitere manuelle QA durch Designer, Consultant oder Kunden.

Wenn diese Überprüfungen erfolgreich verlaufen, markiert der Entwickler den Pull Request als “ready for review”, was darauf hinweist, dass die Anpassungen in den Main Branch gemerged werden können. Im nächsten Schritt durchlaufen die Codeänderungen weitere manuelle Checks:

• Code Review durch den Code Owner: Unsere Teammitglieder haben verschiedene Rollen, wobei die Code Owner für einen bestimmten Teil unseres Quellcodes verantwortlich sind und daher vor dem Merge Code Reviews durchführen.
• Genehmigung durch einen Admin: Ein Admin muss den Pull Request genehmigen, bevor ein Merge möglich ist.

Zweiter Trigger für die CI/CD-Plattform: Merge in den Main Branch

Nur wenn alle Überprüfungen erfolgreich sind und die Branch Protection Rules eingehalten wurden, kann der Pull Request in den Main Branch gemerged werden. Sobald dies geschieht, wird ein weiterer Auslöser getriggert, der die Staging Pipeline startet. Die Staging Pipeline erstellt eine weitere Testumgebung, die den Status Quo unseres Main Branches widerspiegelt. Hier werden alle Änderungen des Teams zusammengeführt.

Ausführung der Staging Pipeline

Die notwendigen Schritte zur Erstellung unseres Staging Builds sind im Wesentlichen die gleichen wie in der Preview Pipeline, mit unbedeutenden Unterschieden:

• Kein Link zurück zum Pull Request: Dieser Schritt wird nur in der Preview Pipeline ausgeführt.
• Status Reports: Rückmeldung an den Main Branch auf GitHub anstelle des Pull Requests.

Staging Umgebung

Nach erfolgreicher Integration aller Änderungen und Deployments funktionsfähiger Builds aller Apps in Staging sind wir nun an einem Punkt angekommen, wo sich unser Code immer in einem releasefähigen Zustand befinden sollte. Das Staging-Projekt wird mit unserem Kunden geteilt und dient zur unabhängigen Prüfung aller Integrationen sowie zur Sicherstellung der reibungsloser Funktionsweise von internen Skripten und Tracking. Es ist höchst unwahrscheinlich, dass zu diesem Zeitpunkt noch etwas schiefgeht und im Prinzip können Releases ab sofort von jedem Entwickler jederzeit durchgeführt werden.

Production Release

Durch die Einhaltung dieser CI/CD Praktiken eliminieren wir jegliche Integrations- und Testphasen sowie Code Freezes. Unser Produkt bleibt während seines gesamten Lebenszyklus deployable und jeder kann schnell und automatisiert Feedback zur Produktionsbereitschaft seines Codes erhalten.

Im nächsten Beitrag dieser Serie werden wir Einblicke in unseren Production Release Prozess geben und diese Blogreihe mit einigen abschließenden Gedanken abrunden.