CircleCI vs. Google Cloud Build

Das perfekte CI/CD-Tool für euer Projekt zu wählen, kann schwierig sein. In diesem Beitrag vergleichen wir zwei Managed CI/CD-Services: CircleCI und Google Cloud Build. Sami Alajrami bewertet dieses spannende CI/CD-Duell.

Früher bedeutete Continuous Integration im Team, dass ihr einen CI/CD-Server wie Jenkins oder TeamCity installieren und verwalten musstet. Ein paar Jahre später haben die Herausforderungen bei der Verwaltung selbst gehosteter CI/CD-Server zum Aufstieg von Managed CI/CD-Lösungen geführt.

Anbieter von Managed CI/CD-Services nehmen euch den operativen Wartungsaufwand ab, damit sich euer Team auf die Softwareentwicklung konzentrieren kann. Solche Lösungen unterscheiden sich jedoch oft in ihren Funktionen und Kostenmodellen und passen nicht immer zu den Anforderungen eurer Projekte. Das kann dazu führen, dass ihr für alle oder Teile eurer Projekte weiterhin eine selbst gehostete Lösung nutzen müsst. Zudem haben verschiedene Anbieter von Managed CI/CD-Services unterschiedliche Stärken und Schwächen. Eine Lösung, die für alle passt, gibt es nicht.

Mehr über die Unterschiede zwischen selbst gehostetem und Managed CI/CD könnt ihr hier lesen.

Vergleich

Kürzlich hat uns ein Kunde gebeten, zwei Managed CI/CD-Services zu bewerten: CircleCI und Google Cloud Build (GCB). So sollte er die Lösung auswählen können, die seine Anforderungen am besten erfüllt. Dieser Beitrag fasst unsere Erkenntnisse zusammen.

Für den Vergleich haben wir dasselbe Kundenprojekt mit beiden CI/CD-Services gebaut und die beiden im Kontext dieses Projekts gegenübergestellt. Das betreffende Projekt ist eine Open-Source-Monorepo-Kotlin-Anwendung, die mit Gradle gebaut wird. Obwohl der Vergleich im Kontext eines kundenspezifischen Projekts durchgeführt wurde, sind die Ergebnisse recht allgemein übertragbar. Wir haben die beiden Services anhand der folgenden Faktoren verglichen:

Reifegrad der Benutzeroberfläche

Gewinner: CircleCI

CircleCI ist bereits seit einiger Zeit am Markt und hatte daher Zeit, seine Benutzeroberflächen zu optimieren. Ihr könnt einfach auf Builds und Workflows zugreifen sowie Logs einzelner Schritte in euren Build-Jobs einsehen. GCB muss mehr in seine Benutzeroberfläche investieren.

Debugging-Unterstützung

Gewinner: CircleCI

Zu Beginn eines Projekts ist es sehr wahrscheinlich, dass eure Workflows und Skripte Fehler enthalten und mehrmals fehlschlagen, bevor ihr sie perfektioniert habt. In solchen Fällen sind Möglichkeiten zum Debuggen eurer Workflows und Jobs entscheidend. CircleCI ermöglicht es euch, einen Job mit SSH erneut auszuführen. Das bedeutet, dass ihr euch über SSH mit dem laufenden Build-Container bzw. der VM verbinden könnt. Außerdem stellt CircleCI ein lokales CLI-Tool bereit, mit dem ihr die CircleCI-Umgebung lokal nachstellen könnt – sehr hilfreich beim Debugging. GCB bietet keine Debugging-Unterstützung.

Integrierte Benachrichtigungen

Gewinner: CircleCI (aber nur knapp!)

CircleCI gewinnt diese Kategorie, weil es standardmäßig Benachrichtigungen per E-Mail, Slack, HipChat, Flowdock, Campfire und IRC unterstützt, während GCB keine davon unterstützt. Allerdings sind CircleCI-Benachrichtigungen nicht immer hilfreich; siehe beispielsweise hier. CircleCI hat seine Benachrichtigungen kürzlich aktualisiert. Dennoch müsst ihr möglicherweise eigene, benutzerdefinierte Benachrichtigungen als Teil eurer Workflows implementieren – was auch mit GCB möglich ist.

Integrationen mit Cloud-Anbietern

Gewinner: Google Cloud Build

CircleCI 2.0 verfügt über keine speziellen Integrationsmechanismen für bestimmte Cloud-Anbieter. Ihr müsst euch daher aus euren Jobs mit eurem Anbieter verbinden, wie von jeder anderen Maschine aus auch. Dafür müsst ihr zudem Zugangsdaten bereitstellen.

GCB hingegen ist Teil der Google Cloud Platform (GCP) und kann ohne zusätzliche Zugangsdaten auf verschiedene GCP-Services zugreifen.

GCB gewinnt jedoch nur in bestimmten Fällen. Wenn ihr andere Anbieter nutzt oder euch nicht an einen Anbieter binden möchtet, ist diese GCB-Funktion nutzlos.

Risiko einer Anbieterbindung

Gewinner: Keiner!

CircleCI ist neutral, da es mit jedem Cloud-Anbieter genau gleich funktioniert. Google Cloud Build ist eindeutig – und verständlicherweise – auf Google Cloud ausgerichtet. Es bietet euch eine einfache Integration mit anderen GCP-Services, was dazu führen kann, dass ihr eure Projekte auf GCP-spezifischen Services aufbaut. Eine Bindung an GCP kann jedoch akzeptabel sein, wenn die Auswahl der Services dies rechtfertigt.

Deklarative Konfiguration

Gewinner: CircleCI

CircleCI bietet im Vergleich zu GCB eine ausgereiftere und funktionsreichere deklarative Workflow-Konfiguration. In CircleCI könnt ihr beispielsweise Filter für benutzerdefinierte Builds auf bestimmten Tags oder Branches konfigurieren. In GCB lässt sich dasselbe erreichen, allerdings müsst ihr dafür Trigger verwenden, die über die Benutzeroberfläche der Konsole und nicht als Teil der deklarativen Konfiguration eingerichtet werden. GCB bietet zudem eine praktische Funktion, mit der ihr eure Workflows auf verschiedene Dateien aufteilen und unterschiedlichen Triggern zuordnen könnt. Für den Sieg in dieser Kategorie reicht das allerdings nicht.

Verfügbare Build-Infrastruktur

Gewinner: Keiner

CircleCI unterstützt drei Arten von Executoren: Docker-Container, virtuelle Maschinen und macOS. Für Docker-Container könnt ihr zusätzliche Rechenressourcen mit bis zu 8 vCPUs und 16 GB RAM erwerben.

GCB bietet nur Docker-Container als Executor. Allerdings stellt es eine VM bereit, auf der alle eure Build-Container laufen. Die VM kann einen von zwei Maschinentypen verwenden (maximal 32 vCPUs/28,8 GB RAM). Der Vorteil, alle Container auf einer einzelnen VM auszuführen, besteht darin, dass in Google Cloud Build alle eure Jobs im selben Docker-Netzwerk laufen und standardmäßig auf Artefakte aus vorherigen Jobs zugreifen können. In CircleCI müsst ihr Artefakte im Workspace persistieren und dort einbinden, wo sie benötigt werden. Das führt zu mehr Zeilen in eurer CircleCI-Konfiguration und kann die Ausführungszeit verlängern – abhängig von der Größe eurer Artefakte.

Feedback an GitHub

Gewinner: CircleCI

Es ist sehr wichtig, die Ergebnisse eurer Builds in den GitHub Checks sehen zu können. CircleCI unterstützt dies standardmäßig. GCB hat vor Kurzem eine Alpha-Version seiner GitHub App eingeführt. Diese App kann Builds auslösen und Feedback an GitHub übermitteln. Derzeit funktioniert sie jedoch nicht mit Triggern. Das bedeutet, dass sie nicht nutzbar ist, wenn ihr benutzerdefinierte Branch- oder Tag-Filter in Triggern konfiguriert habt. CircleCI unterstützt Builds ausschließlich aus Pull Requests. GCB unterstützt keine Builds von Pull Requests aus Forks.

Secret Management

Gewinner: Keiner

Die meisten Projekte müssen während Build-, Test- und Deployment-Jobs Secrets übergeben. Die Art, wie diese Secrets übergeben und verwaltet werden, ist wichtig, denn ihr möchtet nicht, dass eure Secrets offengelegt werden oder in falsche Hände geraten. Bei beiden Services müsst ihr einem Drittanbieter eure Secrets anvertrauen.

CircleCI verwendet HashiCorp Vault, um Secrets zu verschlüsseln, und speichert sie als Umgebungsvariablen, die den Jobs zur Verfügung stehen. Das Risiko besteht darin, dass CircleCI bei öffentlichen Repositories alle eure Job-Logs öffentlich macht. Deshalb müsst ihr darauf achten, Secrets nicht in euren Jobs zu protokollieren. Außerdem kann jeder GitHub-Nutzer mit Schreibberechtigung für das Repository eine erneute Ausführung mit SSH starten und alle Umgebungsvariablen, einschließlich der Secrets, ausgeben.

GCB verwendet Google KMS, um Secrets zur Laufzeit zu entschlüsseln und als Umgebungsvariablen bereitzustellen. Das bedeutet, dass ihr manuell einen KMS-Schlüssel erstellen und damit euer Secret verschlüsseln müsst. Anschließend fügt ihr das verschlüsselte Secret in eure versionierte GCB-Konfigurationsdatei ein, und GCB entschlüsselt es zur Laufzeit. Beachtet jedoch, dass die Größe eines verschlüsselten Secrets auf 2 MB begrenzt ist. Eine JSON-Datei für ein Google-Cloud-Servicekonto kann diesen Wert verschlüsselt häufig überschreiten. Dann müsstet ihr sie in einem Google-Bucket speichern und die Datei zur Laufzeit abrufen, da der Zugriff auf Buckets ohne Anmeldedaten möglich ist.

Preise

Gewinner: Google Cloud Build

GCB bietet 120 kostenlose Build-Minuten pro Tag und bis zu 10 parallele Builds. Danach werden für den Standard-VM-Maschinentyp 0,003 $ pro Minute berechnet (Details findet ihr hier). CircleCI bietet monatlich 1.500 kostenlose Build-Minuten und einen parallelen Job für Linux-Builds. Für jeden zusätzlichen parallelen Container werden 50 $ pro Monat berechnet. Für macOS-Builds gelten andere Preise (Details findet ihr hier).

Zusammenfassung

Es ist ziemlich klar, dass CircleCI im Vergleich zum jüngeren Google Cloud Build einen ausgereifteren und funktionsreicheren CI/CD-Service bietet. Die Wahl eines Tools sollte jedoch immer von den spezifischen Anforderungen des Projekts abhängen. Wenn ihr beispielsweise bereits mehrere Services von Google Cloud nutzt und euch die oben genannten Einschränkungen von GCB nicht stören, ist GCB eine sinnvolle Wahl. Wenn GCB aktuell nicht für euch funktioniert, lohnt es sich dennoch, seine Entwicklung im Blick zu behalten – auch wenn der Fortschritt in der Vergangenheit langsam zu sein schien.

Was wirklich zählt, ist, dass ihr eine fundierte Entscheidung trefft. Das Tool ist nicht so wichtig wie die Art, wie ihr es nutzt. Ihr solltet kein Tool auswählen und eure Arbeitsweise an seine Funktionen anpassen. Versucht stattdessen, das Tool an eure Anforderungen anzupassen, solange ihr Best Practices befolgt. Kennt eure Anforderungen sowie die Kompromisse und Einschränkungen der Tools. Dann könnt ihr das Tool wählen, das für euch am besten funktioniert.