Umstellung von Jenkins auf GitHub als CI/CD-System

Im April 2020 kündigte GitHub seine eigene CI/CD-Plattform an, und dank des Unternehmensvertrags stand uns quasi über Nacht eine Alternative zu CircleCI zur Verfügung. Da wir bereits die Github Package Registry für Docker-Images und NPM-Pakete nutzen, wollten wir die neuen Aktionen unbedingt ausprobieren. Unser erster Eindruck war jedoch eher ernüchternd - die Aktionen wirkten unfertig und fremd. Außerdem war eine 1:1-Migration unmöglich. Das Konzept der manuellen Gates, das wir bei CircleCI für Deployments verwenden, gibt es dort nicht. Bisher haben wir es als beruhigend empfunden, dass die Pipelines die Software auf den Live-Systemen auch nach erfolgreicher Prüfung nicht ohne unser Zutun aktualisieren - manche Änderungen müssen sehr genau überwacht werden. Ein manuelles Gate erlaubt es uns nur dann, Code zu verteilen, wenn wir die Kapazitäten für die Überwachung und ein Rollback haben.
Da wir in den letzten zwei Jahren viel Arbeit in unsere CircleCI-Workflows gesteckt haben, hatten wir kein Interesse daran, wieder von vorne anzufangen.
Nach einem ersten Proof of Concept änderte sich unsere Meinung zum Besseren und wir beschlossen, den Schritt zu wagen.
Wir haben in den letzten Wochen insgesamt 64 CircleCI-Pipelines auf GitHub migriert und können nun stolz GitHub Actions willkommen heißen!

Bevor wir mit dem Umzug begonnen haben, haben wir die Gemeinsamkeiten zwischen unseren Pipelines identifiziert.
Alle unsere Pipelines:

• durchlaufen einen Build-Schritt (in unserem Team speziell: npm ci und npm run build)
• Unit/Interaktionen/E2E-Tests ausführen (npm run test)
• Abhängigkeiten prüfen (npm audit)
• Software-Lizenzen prüfen, da wir nicht alle Lizenzen nutzen dürfen
• Dokumentation in einem zentralen S3-Bucket bereitstellen.

Außerdem haben wir drei Arten von Pipelines:

1. Pipelines, die innerhalb der AWS-Infrastruktur bauen (terraform apply) und dann Software ausrollen
2. Pipelines, die Software als NPM-Paket oder Docker-Image bereitstellen
3. Pipelines, die beides erfordern.

Pipelines, die Auswirkungen auf den Kunden haben, melden ihre Bereitstellung auch an eine zentrale Überwachungsfunktion.
Daneben gibt es noch folgende Regeln:

• Feature-Zweige benötigen ein Gate, um auf ein Entwicklungssystem ausgerollt zu werden
• nur der Hauptzweig kann ein Live-Deployment hinter einem Gate starten.

Für alle Anforderungen konnten wir entsprechende GitHub-Workflows erstellen. Nur die Gates konnten nicht abgebildet werden. Stattdessen verwenden wir für ein Deployment den Trigger "Released", der über die GitHub GUI oder die GitHub API aktiviert werden kann. Für Deployments, die nur bis zum Entwicklungssystem ausgerollt werden sollen, verwenden wir Prereleases.

Ein weiterer Vorteil ist, dass JavaScript bei GitHub Actions ein First Class Citizen ist. Das ist sehr praktisch für unser Team, das sich mit Node.js am wohlsten fühlt.

Pipelines, insbesondere wenn sie sehr ähnlich sind, sind leider anfällig für Code-Duplikationen. Bei CircleCI verwenden wir Orbs und YAML-Anker, um sicherzustellen, dass wir DRY - 'Don't Repeat Yourself' - bleiben.
Ein Deployment auf unserem Entwicklungssystem unterscheidet sich beispielsweise genau in einem Punkt von einem Live-Deployment - der Zielumgebung (Live statt Develop). Alle anderen Schritte sind völlig identisch. In den YAML-Dateien für CircleCI konnten wir über Anchors und Aliases eine einzige Quelle der Wahrheit schaffen, so dass wir nur an einer Stelle Änderungen vornehmen müssen.
Da wir über Pipelines verfügen, die in bis zu 6 verschiedenen AWS-Konten bereitgestellt werden, konnten wir einen Großteil unseres identischen Codes herausschneiden und einen klaren Überblick über den Workflow behalten. Orbs haben uns dabei geholfen, Code über alle Pipelines hinweg wiederzuverwenden.
Leider gibt es auf GitHub Actions keine Anker und diese Funktion wird von der Community schmerzlich vermisst. GitHub ist sich dieses Schmerzpunktes bewusst; bisher gab es jedoch nur eine Ankündigung, dass sie daran arbeiten.
Da wir aber keinesfalls anfangen wollten, Code zu duplizieren, haben wir eine Anwendung namens Gitty geschrieben, die Workflows in allen Repositories über die GitHub API aktualisiert.
In jedem Repo haben wir eine Konfiguration, die Gitty über die GitHub API liest. Aus der Config werden YAML-Workflows generiert und per Commit wieder eingecheckt. Unser anfänglicher intensiver Aufwand hat sich schnell ausgezahlt.

Beispiel:
Als kürzlich bekannt wurde, dass set-env bald deaktiviert wird, mussten wir den Code an nur einer Stelle anpassen, um alle Repositories zu aktualisieren (mehr dazu).

Pipelines außerhalb von AWS benötigen Credentials, um Ressourcen innerhalb von AWS zu erstellen. Bei CircleCI hatten wir die AWS-Anmeldeinformationen bereits über Lambda und API verteilt und sie regelmäßig rotiert. Dies ist auch mit GitHub möglich. Aber Vorsicht! Bei der GitHub-API schlägt der Mechanismus zur Missbrauchserkennung schnell zu. Eine unbegrenzte Promise.all() gegen alle Repos löst eine sehr flotte 403 aus.

Leider kann ein KI-System immer abstürzen. Bei CircleCI war das in den letzten Jahren selten der Fall, aber wenn es tatsächlich mal passiert ist, dann immer zum falschen Zeitpunkt. Wir haben daher alle Pipelines so konzipiert, dass sie auch lokal ausgeführt werden können.
Deshalb verwenden wir in der Pipeline eine AWS-Rolle, die auch von unseren lokalen AWS-Benutzern "übernommen" werden kann. So scheitert eine Bereitstellung nicht mehr an einer fehlenden IAM-Richtlinie. Zum Glück gibt es nur wenige Kernanforderungen an einen Entwicklungsrechner: Node.js, Terraform, Git, GITHUB_TOKEN und AWS Credentials reichen aus, um alle Dienste lokal zu erstellen, zu testen und bereitzustellen. Diese Unabhängigkeit wollen wir in jedem Fall beibehalten. Während CI-Systeme einen Großteil der harten Arbeit erledigen, sollten sie niemals die einzigen Systeme sein, die im Notfall für die Bereitstellung von Code zur Verfügung stehen.

Wir sind jetzt sehr zufrieden mit GitHub Actions und mussten in den letzten Wochen kaum noch Anpassungen vornehmen. Die Jobs laufen schnell und stabil. Wartezeiten gibt es bei uns im Moment nicht, obwohl es auch hier bald eng werden könnte.
Ein Wechsel des CI-Systems ist immer eine gute Gelegenheit für einen Frühjahrsputz, und den haben wir auch genutzt. Die enge Verzahnung mit GitHub hat sich dabei als großer Vorteil erwiesen. Wir sind wirklich froh, den Wechsel gewagt zu haben und wollen diese Lösung in Zukunft nicht mehr missen!