Ein erster Eindruck von GitHub Actions CI/CD

Dies ist eine klare Reaktion auf die Einführung ähnlicher Tools durch andere Anbieter. In diesem Beitrag gebe ich euch auf Basis von Recherche und Praxistests einen ersten Eindruck. GitHub Actions habe ich nicht mit möglichen Wettbewerbern verglichen.

Einführung in GitHub Actions

Actions fiel mir leicht, da ich mit verschiedenen CI-Systemen wie Travis CI und CircleCI vertraut bin. Gemeinsam ist ihnen die Auszeichnungssprache YAML. GitHub Actions unterstützt die drei wichtigsten Betriebssysteme Windows, MacOS und Linux. Darauf könnt ihr jede Programmiersprache ausführen, die von diesen Betriebssystemen unterstützt wird.

Neben Pull Requests und Commits können Actions auf jedes GitHub-Ereignis reagieren. Damit könnt ihr bestimmte GitHub-Actions-Workflows – einschließlich Open-Source-Actions – basierend auf Folgendem auslösen:

• der Erstellung von Issues

• Kommentaren

• dem Beitritt eines neuen Mitglieds zum Repository

• Änderungen am GitHub-Projektboard.

Actions bietet eine starke Integration mit GitHub, sodass kein zusätzlicher Anbieter für CI erforderlich ist. Aus geschäftlicher Sicht ist dies eine klare Reaktion auf GitLab und dessen CI-Angebot sowie auf Azure DevOps.

Syntax

Im folgenden Code zeige ich einen Workflow, der bei „push“ ausgelöst wird – also bei jedem Code-Commit in unser Repository. Unser konkreter Workflow konfiguriert Golang und seine Abhängigkeiten und führt anschließend die Binärdatei aus, die „Hello World!“ ausgibt.

Actions bietet Live-Logs während der Builds und liefert so direktes Feedback. Eine Farbcodierung und einklappbarer Code sorgen für mehr Übersichtlichkeit.

Die Logs eines Workflow-Runs lassen sich wie unten dargestellt live anzeigen. Diese Ausgabe stammt aus einem Workflow mit einem Job, der Go einrichtet, die Golang-Abhängigkeiten abruft und installiert und anschließend die Datei run.go ausführt. Diese Datei enthält Code, der „Hello, World!“ ausgibt.

Der obige Codeausschnitt stammt aus meinem GitHub-Account.

Community-gestützte Workflows

Öffentlich verfügbare Workflows, sogenannte Community-gestützte Workflows, werden von der großen GitHub-Community erstellt und ermöglichen wiederverwendbare Workflows. Dieses Engagement der Community führt zu hochwertigem Code, der von einer breiteren Community getestet und geprüft wird und im GitHub Marketplace veröffentlicht ist.

Ein bemerkenswerter positiver Nebeneffekt ist, dass der Workflow kontinuierlich optimiert wird.

Die Liste der Actions wächst schnell. Das könnte bei der Softwareentwicklung viel Zeit sparen, da Entwickler nicht jedes Mal das Rad neu erfinden müssen. Daneben gibt es eine von GitHub unabhängige Community für geteilte GitHub Actions, die kontinuierlich wächst, da Entwickler Interesse an gemeinsam genutzten Workflows zeigen.

Sowohl der GitHub Marketplace als auch die Netlify-basierte Community zum Teilen von Workflows sind öffentlich. So kann jeder zu den Actions beitragen und sie nutzen. Organisationen, die Workflows privat teilen möchten, müssen dies über selbst erstellte Repositories auf GitHub tun.

Das Repository verfügt dann über eine Schaltfläche „Include action in your project“, mit der ihr die Action einfach zum Repository eurer Wahl hinzufügen könnt. Dadurch lassen sich Workflows sowohl öffentlich als auch privat teilen.

Persistenz von Workflow-Daten durch Artefakte

GitHub Actions unterstützt die Persistenz von Workflow-Daten durch Artefakte. Ein Workflow mit mehreren Jobs kann Daten aus vorherigen Jobs speichern und verarbeiten. Dadurch können Entwickler Workflows optimieren und saubereren, effizienteren Code schreiben.

Im folgenden Code zeige ich dies anhand eines Beispiels. Der Workflow besteht aus drei Jobs, die voneinander abhängig sind, und demonstriert die Wiederverwendbarkeit von Code.

Das Artefakt kann nach Abschluss des Workflow-Runs heruntergeladen werden. In diesem Fall handelt es sich um eine .txt-Datei mit der Zeichenfolge „Hello World!“. Sie wurde mit zwei separaten Jobs in der Shell nach stdout ausgegeben und während jedes Jobs in der Artefaktdatei gespeichert.

Ein Nachteil besteht darin, dass sich dieses Artefakt nicht einzeln über die GitHub API abrufen lässt. Die API erlaubt nur das Herunterladen der vollständigen Archivausgabe. Wie das Beispiel zeigt, funktioniert die Artefaktfunktion über Betriebssysteme hinweg.

Jobs werden standardmäßig parallel ausgeführt. In diesem Fall habe ich Abhängigkeiten zu anderen Jobs definiert, wodurch sie nacheinander ausgeführt werden.

Abhängigkeiten und Build-Ergebnisse cachen

GitHub hat kürzlich die Funktion zum Cachen von Abhängigkeiten und Build-Ergebnissen veröffentlicht, um die Ausführungszeit von Workflows zu verkürzen.

Wenn ein Job ausgeführt wird, erfolgt dies in einer sauberen Umgebung, in der alle Abhängigkeiten und benötigten Pakete heruntergeladen werden. Bei der Entwicklung und beim Deployment eurer Projekte kann das viel Zeit kosten. Mit der Caching-Funktion könnt ihr vermeiden, dass das wiederholte Herunterladen großer Datenmengen zum Engpass wird. Auf den ersten Blick klingt das sehr ähnlich wie der vorherige Abschnitt zur Persistenz von Workflow-Daten – und das stimmt auch.

Der Unterschied liegt im Anwendungsfall: Das Cachen von Abhängigkeiten ist für Dateien gedacht, die sich innerhalb von Jobs nicht ständig ändern. Workflow-Datenpersistenz eignet sich besser für Daten, die durch mehrere Jobs im Workflow fortlaufend verändert werden.

Caching wird in der YAML-Datei eingerichtet, indem Folgendes definiert wird:

• „path“: ein Verzeichnis zum Speichern des Caches.

• „key“: ein eindeutiger Schlüssel zum Wiederherstellen und Speichern des Caches.

• „restore keys“: eine Liste weiterer Schlüssel, die versucht werden, wenn der erste Schlüssel keinen Treffer liefert.

Der Schlüssel identifiziert den jeweiligen Cache und ermöglicht seine Wiederverwendung, wenn ein „cache-hit“ erkannt wird. Wird ein „cache-miss“ erkannt, wird die Anweisung ignoriert. Das Modell ähnelt der Caching-Funktion von CircleCI, die Keys und restore_keys/caches verwendet.

Johan Abildskov, DevOps Engineer bei Eficode Praqma, hat ein Beispiel für Caching mit Actions geschrieben, das ihr euch ansehen solltet.

Workflow-Eigenschaften

Das manuelle Auslösen von Workflow-Ausführungen fehlt derzeit noch. Über die GitHub API ist es zwar möglich, aber im Hinblick auf Betrieb und Developer Experience mit CI/CD-Systemen nicht ideal.

Diese fehlende Funktion erschwert das Debugging und kann die User Experience für Entwickler beeinträchtigen. Nach Abschluss des Builds kann das Build-Ergebnis über die GitHub-Actions-Seite heruntergeladen werden.

Matrix-Builds

Wenn euer Team Software mit mehr als einer unterstützten Version einer Sprache, eines Betriebssystems oder eines Tools erstellt, könnt ihr mit GitHub Actions über Matrix-Builds diese Varianten ausführen.

Jede Konfiguration in der Matrix ist eine Kopie des Jobs, die ausgeführt wird und einen Status meldet.

Im Code-Snippet auf der nächsten Seite habe ich einen Matrix-Build gezeigt. In der Zeile „runs-on“ lese ich die Werte der Liste „matrix-os“, indem ich ihr Array durchlaufe, das Verweise auf vier Betriebssysteme enthält: zwei Ubuntu-Versionen, macOS und Windows.

Das bedeutet, dass vier Jobs von `job_1` ausgeführt werden. Jeder läuft auf einem anderen Betriebssystem und erzeugt eigene Logs sowie dieselbe Ausgabe, da ich dies in meiner Workflow-Datei festgelegt habe.

Die Matrix-Builds-Funktion wird vermutlich intensiv von Entwicklern genutzt, die DevOps/NoOps praktizieren, und spart viel Zeit bei der Erstellung von Entwicklungs-Workflows.

Self-hosted Runner

Mit GitHub Actions könnt ihr Workflows auf den Servern von GitHub oder mit der Funktion self-hosted runners auf euren eigenen Servern ausführen.

Preismodell

Actions ist für öffentliche Repositories vollständig kostenlos. Für private Repositories gilt ein „Pay-as-you-go“-Modell pro Minute. Das ist mehr als beispielsweise CircleCI in seinem kostenlosen Tarif bietet.

Fazit

GitHub Actions hat in der GitHub-Community große Aufmerksamkeit erlangt. Für die Nutzung ist nur eine minimale Konfiguration erforderlich: Ein einfacher Klick auf einen Button auf der Seite eurer GitHub-Repositories startet die Einrichtung einer CI/CD-Pipeline. So können sich Entwickler auf die Entwicklung konzentrieren, statt beispielsweise Server für Jenkins einzurichten oder sich bei anderen Anbietern wie CircleCI anzumelden.

Sowohl während der Beta-Phase als auch nach dem Release gab es nur wenige offizielle Informationen zu Funktionen, die sich noch in Entwicklung befinden. Daher lässt sich die Go-to-Market-Strategie nur schwer einschätzen. Dass GitHub nun CI-Funktionen anbietet, ist angesichts der großen Community, die GitHub bereits nutzt, ein bedeutender Schritt. Gleichzeitig ist es eine naheliegende Entwicklung, da Wettbewerber wie GitLab diese Funktion schon seit einiger Zeit anbieten und Automatisierung zunehmend an Bedeutung gewinnt.

Zum Zeitpunkt der Veröffentlichung war Actions erst seit wenigen Tagen vollständig verfügbar und hatte sich in der Branche noch nicht bewährt. Für Entwickler ist dies zwar ein vielversprechender und willkommener Schritt, doch bevor Produktions-Workloads darauf laufen, ist es vielleicht sinnvoll, noch etwas abzuwarten.