GitHub Actions ist in aller Munde und es gibt von GitHub schon mehr als genug Informationen. Wir möchten in unserer Blogserie GitHub Actions die Umstellung von Azure Pipelines auf GitHub Actions anhand eines praktischen Beispiels zeigen. Dazu stellen wir uns zuerst folgende Fragen: Ist die Migration von Azure DevOps Pipeline nach GitHub Actions sinnvoll? Wenn ja, wie migriert man nach GitHub Actions? Wenn nein, wann lohnt sich überhaupt der Einsatz von GitHub Actions? Diese und weitere Fragen werden wir in dieser Blogserie mit den Grundlagen zu GitHub Actions klären – beispielhaft anhand unseres Tools Voting Extension. Wir haben eine Migration der Voting Extension von Azure DevOps Pipeline nach GitHub Actions durchgeführt. Diese Erfahrung möchten wir mit Ihnen teilen und dabei mögliche Stolpersteine aufweisen.
Wie sinnvoll die Migration nach GitHub Actions ist, hängt von vielen Faktoren ab. Eine typische Antwort eines Beraters würde auf folgende Weise anfangen: “Es kommt darauf an…”.
Zum einen ist es eine Geschmacksfrage und hängt davon ab mit welcher Technologie man gerne und häufig arbeitet. Der nötige Wissensaufbau für eine Technologie/Plattform und die Akzeptanz dafür in einem Team sollte nicht unterschätzt werden.
Zum anderen ist noch wichtig, dass der aktuelle Funktionsumfang von GitHub Actions ausreichen soll, um den Anforderungen der Pipeline bzw. Workflows gerecht zu werden. Im Vergleich zu Azure DevOps ist GitHub Actions noch nicht lange auf dem Markt und hat daher einen kleineren Funktionsumfang. Aber Microsoft investiert aktuell mehr in die Entwicklung von GitHub Actions als von Azure DevOps Pipeline. D.h. GitHub Actions wird vermutlich in Zukunft vermisste bzw. gewünschte Features erhalten.
Wer also aus dem Microsoft-Umfeld kommt und gerne und häufig damit arbeitet, für den ist die Migration einer bestehenden Azure DevOps Pipeline meist erstmal nicht sinnvoll. Dies ist bei uns zwar der Fall, jedoch wollen wir bei AIT gerne andere und neue Technologien kennenlernen. Deshalb haben wir die Migration und die Benutzung von GitHub Actions an unserem Tool VotingExtension ausprobiert.
In der Regel wird man also eine bestehende Azure DevOps Pipeline nur in besonderen Fällen migrieren (z.B. wenn das Team mehr Erfahrung mit GitHub hat). Aber bei neuen Projekten kann es durchaus sinnvoll sein, sowohl Code als auch die Pipeline bei GitHub zu hosten und damit eine nahtlose Integration zu haben – sofern der Funktionsumfang ausreichend ist.
Am Ende haben wir uns gegen eine Migration unserer Azure DevOps Pipeline der VotingExtension nach GitHub Actions entschieden, da ein für uns wichtiges Feature (noch) fehlt. Dies wird in einem späteren Blogartikel dieser Serie erläutert werden. Zuerst erklären wir die erste Grundlage, womit man bei GitHub Actions anfangen kann: die Einrichtung eines GitHub Workflows.
Einrichtung GitHub Workflow
Ein GitHub Workflow ist vergleichbar mit einer Azure DevOps Builddefinition. Ein Workflow ist ein benutzerdefinierter automatisierter Prozess, der in einer Workflow-Datei im YAML-Format definiert wird. Diese Datei kann im GitHub Repository erstellt werden, um Projekte zu bauen, zu testen und paketiert auszuliefern.
Um einen GitHub Workflow zu erstellen, muss erstmal über das GitHub Repository nach “Actions” navigiert werden.
Abb. 1: Navigation zu GitHub Actions
Wenn schon Workflows erstellt und ausgeführt wurden, kommt diese Ansicht (Abb. 2). Sonst ist sofort die nächste Ansicht zusehen (Abb. 3).
Abb 2. Navigation zur Erstellung neuen Workflows
Dann wählen wir einen einfachen Standard Workflow aus, indem wir auf „set up a workflow youerself“ (1) oder Set up this Workflow (2) klicken. Beides führt zum jetzigen Zeitpunkt zu selbem Ergebnis (wahrscheinlich eine falsche Verlinkung, denn der erste Link sollte zu einem leeren Workflow führen). Mit diesem von GitHub vorgeschlagenen Beispiel (basierend auf dem Inhalt des Repositoriys) fahren wir fort und zeigen am Ende, wie dieses ausgeführt wird. Es ist auch möglich vom leeren Workflow zu beginnen. Dazu einfach eine YAML-Datei im Repository unter „.github/Workflow“ erstellen.
Abb. 3: Anlegen eines neuen Workflows
Zum Start hilft die Dokumentation auf der rechten Seite mit der Syntax (4). Dazu die Dokumentation über den Tab “Documentation” öffnen (3). Beim Editor hilft die Autovervollständigung über “Strg” + “Space” sehr gut (5).
Abb. 4: Editieren des Workflows
Es können hier beliebig viele Anpassungen am Workflow vorgenommen werden. Für dieses Beispiel bleiben wir minimalistisch für die Verständlichkeit. Wer gerne den Namen der YAML-Datei ändern will, in welcher dieser Workflow abgespeichert wird, kann dies im oberen Feld geschehen (6). Weiter kann auch der Name dieses Workflows angepasst werden, dies passiert unter „name“ (7). In diesem Beispiel bleibt der Name „CI“.
Abb. 5: Name vom Workflow
Um den Workflow zu speichern, muss ein Commit erzeugt werden. Wir wollen den Commit noch nicht auf den master-Branch erzeugen und testen, sondern zuerst auf einem neuen Branch. Dafür bearbeiten wir ein Feld (8), welches steuert, wann der Workflow ausgelöst wird (hier: beim Push auf unseren neuen Branch). Dort geben wir den Namen des Branches ein, welchen wir gleich erzeugen werden. Dies ist wichtig, damit der Workflow direkt nach dem Commit gestartet wird. Auf der rechten Seite oben das Dropdown öffnen (9) und einen neuen Branch erstellen (10).
Abb. 6: Speichern vom Workflow
Vorsicht beim nächsten Schritt: ggf. nicht gleich den grünen Button „Create pull request“ anklicken. Damit wird ein Pull Request in Richtung des master-Branches erzeugt. Je nach Einstellung benachrichtigt dieser alle Reviewer. Ist dieser Pull Request nach master gewollt? Dies wird individuell entschieden. Für die ersten Tests und Prüfung des Funktionsumfangs ist ein Pull Request nicht notwendig.
Abb. 7: Pull Request nach master-Branch
Der erstellte GitHub Workflow (wie oben beschrieben) kann weiterbearbeitet werden, indem die YAML-Datei normal zum Bearbeiten geöffnet wird. Diese befindet sich im Repository unter „.github/workflows“.
Abb. 8: YAML-Datei unter .github/Workflow
Run vom erstellten Workflow
Nach der Erstellung eines Workflows geht es mit dem Ausführen bzw. Starten eines „Runs“ vom oben erstellten Workflow. Ein Run ist eine Instanz eines Workflows und damit vergleichbar mit einem „Build“ einer Azure DevOps Pipeline.
Wir navigieren im Repository nach „Actions“, wie bei der Einrichtung des Workflows beschrieben wurde. Dort sehen wir den zu unseren erstellten Commit einen Run, welchen wir auswählen. Dieser wurde ausgelöst, weil wir oben bei dem Trigger den aktuellen Branch Namen „First-Workflow-Branch“ gesetzt und diesen Branch erzeugt haben. Die Trigger werden in einem späteren Blogartikel dieser Serie genauer erläutert.
Abb. 9: Run vom erstellten Workflow auswählen
Im linken Navigationsmenü zu „build“ wechseln, dann können wir die einzelnen Schritte dieses Runs sehen. Durch das Aufklappen der einzelnen Schritte ist, das Log zusehen.
Abb. 10: Run Ergebnisse des erstellten Workflows
Nach der Erstellung eines Workflows und dessen Ausführung kann es mit der Migration der Tasks bzw. der Definition einzelner Schritte im Workflow weiter gehen.
Fazit
Das Erstellen und Starten eines ersten, simplen Workflows funktioniert wie erwartet gut. Gerade mit der Dokumentation und Autovervollständigung im Web hilft GitHub beim Einstieg.
Auch wenn wir am Ende die Pipeline der VotingExtension nicht nach GitHub Actions migriert haben, lohnt es sich, GitHub Actions genauer anzuschauen. Microsoft arbeitet weiter daran und der Funktionsumfang wird wachsen und wird damit GitHub Actions für mehr Nutzer attraktiver machen.
Die nächsten Blogartikel werden Stück für Stück die Migration nach GitHub Actions erklären und generell die Verwendung beleuchten. Die Migration der einzelnen Tasks, sowie die Erstellung der Steps wird direkt im nächsten Blogartikel behandelt werden.
Sprechen Sie uns an, wenn Sie Fragen haben oder Unterstützung in Ihrem Softwareentwicklungsprozess benötigen: Von der ersten Idee über die Entwicklung mit einer Build- und Release-Pipeline bis hin zur Inbetriebnahme und Wartung. Wir führen Sie gerne ans Ziel.