Continuous Integration / Continuous Delivery: Vom lokalen Quellcode zum Pull Request

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

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

Source Code Management

Source Code Management (SCM) umfasst die Verwaltung von Änderungen am Softwarecode, welcher in der Regel von mehreren Entwicklern parallel bearbeitet wird. In der Praxis kann dies schnell chaotisch werden. Code-Änderungen werden in zwei Phasen des Entwicklungsprozesses verwaltet. Zunächst auf dem lokalen Rechner jedes einzelnen Entwicklers und zweitens auf GitHub, wo unser Remote-SCM stattfindet. Das Remote-SCM vereinfacht die Kollaboration an gemeinsam verwendetem Code und ermöglicht es uns, Codes zu teilen und gegenseitig manuelle Reviews durchzuführen.

Lokaler Rechner des Entwicklers

Jeder Entwickler arbeitet an einer lokalen Kopie des Projekts. Änderungen am Quellcode werden auf kurzlebigen Feature-Branches vorgenommen. Erste Prüfungen und Tests werden ebenso direkt am lokalen Code selbst durchgeführt:

• Entwickler werden ermutigt, die Build Prozesse lokal auszuführen und die Applikationen auf dem eigenen Rechner zu testen
• Statische Code-Analyse wird durch ESLint gewährleistet, um den Quellcode auf Qualität, Zuverlässigkeit und Sicherheit zu analysieren, ohne den Code dabei auszuführen
• Type Checking zur Kompilierzeit
• Unit-Tests werden lokal ausgeführt
• Automatische Formatierung wird angewendet und Code-Konventionen werden sichergestellt

Während des Entwicklungsprozesses müssen Remote Änderungen regelmäßig abgerufen und in lokale Branches integriert werden, um zu verhindern, dass sie zu weit vom Remote Repository abweichen. Sobald die Code-Änderungen abgeschlossen sind, werden lokale Feature-Branches für das weitere Vorgehen zu GitHub gepusht.

Remote Source Code Management

Sobald der lokale Feature Branch in unser GitHub-Repository gepusht wird, steht der Code für weitere automatische Prüfungen sowie die Zusammenarbeit mit anderen Teammitgliedern zur Verfügung. Als erstes öffnet der Entwickler einen Pull Request. Dieser Pull Request wird im Draft Mode gehalten, bis angegeben wird, dass die Änderungen final sind und in den Main Branch gemerged werden können.

GitHub fungiert dabei als Gatekeeper, indem verschiedene Branch Protection Rules gewährleistet werden. Wir haben hierbei die folgenden Limitierungen aufgesetzt:

• Änderungen im Main Branch dürfen nur per Pull Request erfolgen
• Status Checks müssen vor dem Mergen erfolgreich durchlaufen werden (Builds, Tests)
• Branches müssen vor dem Merge auf dem neuesten Stand sein (keine Konflikte mit Main Branch)
• Manuelle Genehmigung durch Code Owner jedes Pull Requests vor dem Merge ist Pflicht
• Umgehung der o.g. Regelungen ist nicht erlaubt (kann in den GitHub Repository Einstellungen konfiguriert werden)

Brücke zur CI/CD-Plattform

GitHub spielt eine fundamentale Rolle in unserer CI/CD-Praxis, da die direkte Kommunikation mit der CI/CD-Plattform eine essentielle Aufgabe eines jeden Remote-SCM darstellt. Dies kann durch die Integration von Apps, über Webhooks oder, im Fall von GitHub Actions, durch bereits integrierte Funktionalitäten erreicht werden. Wir selbst haben uns für die Integration einer Cloud Build App entschieden. Diese App scannt unseren Code ständig nach Änderungen, um anschließend vordefinierte Automatisierungsprozesse einzuleiten. Das Öffnen eines Pull Requests löst unseren ersten Cloud Build Prozess aus, der mehrere Schritte ausführt, um unseren Entwicklungszyklus weiter voranzubringen und den Code näher zur Produktion zu bringen.

Im nächsten Blogbeitrag dieser Serie werden wir durch die ersten vollständig automatisierten Prozesse führen, die beim Erstellen eines Pull Requests ausgelöst werden.