GitHub-Actions Ein Re­zept für die
automa­ti­sche und zeitsparende
Sicherung Ihrer Code-Qualität

Die GitHub-Küche: Viele Köche arbeiten gemeinsam an einem Code

Stellen Sie sich GitHub einmal wie eine Küche vor, in der viele verschiedene Zutaten vermengt werden und so am Ende ein fertiges Gericht entsteht. Dabei sitzen die Entwickelnden vor ihrem jeweiligen Topf – im Fall des AGOLUTION-Teams ist das meistens Visual Studio Code  (VS Code) – und erstellen ihren individuellen Anteil am Code eines Software-Produktes. Sobald der Code fertiggestellt ist, wird er an GitHub übergeben, um als Erstes den Fortschritt zu sichern. Dabei fungiert GitHub wie eine „Registratur“, indem es ein Abbild des Codes speichert und es damit ermöglicht, an jeden vorherigen „Kochschritt“ zurückzukehren. Denn GitHub dient zuallererst der Versionskontrolle.

Dadurch ist es auch möglich, dass mehrere „Köche“ am selben „Gericht“ arbeiten. Im Gegensatz zum Sprichwort sorgt aber genau diese Parallelität dafür, dass ein Projekt von mehreren Entwickelnden umgesetzt werden kann, ohne dass sie sich ins Gehege kommen. Alle Köche, die an einem Projekt mitarbeiten, erzeugen ihren persönlichen „Kochtopf“, indem sie einen eigenen Zweig (engl. Branch) erstellen, ihren Code hinzufügen und diesen wieder in unsere GitHub-Küche  bringen.

Damit das Gericht am Ende schmeckt: Kontrollen durch Code-Reviews und GitHub-Actions

Bevor dieser Code jedoch einfach in das Projekt „gerührt“ wird, sollten am besten mehrere Kontrollen stattfinden, um das Gericht nicht zu verderben.

In der AGOLUTION-Küche gibt es gleich zwei Kontroll-Komponenten. Erstens bekommen alle Entwickelnden jeweils einen „Beikoch“ in Form eines anderen Entwickelnden zur Seite gestellt. Diese Beiköche führen Code-Reviews durch, das heißt, sie lesen den Programmcode Korrektur und fügen gegebenenfalls Änderungsvorschläge hinzu. Falls ihnen Fehler in der „Zubereitung“ des Codes aufgefallen sind, reichen sie den Topf an den Entwickelnden zurück.

Die zweite Kontroll-Instanz ist automatisiert: die GitHub-Actions. Diese funktionieren wie ein „Scanner“ an der Tür der GitHub-Küche. Sobald die Entwickelnden mit ihrem Topf durch diese Tür treten – indem sie jeweils den frisch entwickelten Code mittels Pull Request zu GitHub überführen – untersucht dieser Scanner den Code. Dabei kommen Workflows und Pipelines zum Tragen. Was tun diese genau?

Workflows und Pipelines – Rezept und Zutaten der GitHub-Actions

Workflows und Pipelines verhalten sich wie „Rezept“ und „Zutaten“. Zuerst brauchen Sie das Rezept, den Workflow. Dort ist hinterlegt, wann genau GitHub den Code untersuchen soll. Bei jedem Pull Request – also schon beim „In-die- Küche-Tragen“? Bei jedem Merge – sprich beim Zusammenführen vom neuen mit dem bestehenden Code? Oder einfach jeden Tag zu einem festgelegten Zeitpunkt?

Außerdem enthält der Workflow die Liste der Zutaten, mit welchen GitHub den Code überprüfen soll. Hier findet sich die Angabe, welche Pipeline für die Überprüfung genutzt wird sowie weitere „Zubereitungsoptionen“, z. B. das Versenden einer Benachrichtigung, sollte ein Fehler bei der Überprüfung auftreten.

Hier sehen Sie den Grundaufbau eines Workflows:

name: Beispiel-Workflow
// Die Bezeichnung des Workflows
on:
// Angabe, zu welchem Zeitpunkt/Ereignis der Workflow einsetzt
env:
// Festlegung für übergreifende Variablen, die Werte für mehrere Jobs vorbelegt und speichert
defaults:
// Hier können Standardparameter angegeben werden, z. B. ob mit PowerShell gearbeitet wird
jobs:
// Auflistung der unterschiedlichen Aufgaben, die abgearbeitet werden sollen, beispielsweise „build“ oder „notify“
  steps:
  // Jeder „step“ gehört zu einem „job“ und beschreibt einen Schritt, der für die Umsetzung durchgeführt werden muss u. a. der Aufruf der Pipeline

GitHub testet die Code-Speise in einer virtuellen Umgebung

GitHub bewahrt Projekte in sogenannten Repositories auf. In unserer AGOLUTION-Küche entspräche das einem großen Regal. Jedes einzelne Regalfach stellt ein Repository dar, in das ein bestimmtes Gericht abgelegt wird.

Neben dem Workflow-Dokument, welches als .yml-Datei in dem Ordner .github\workflows im Repository des zu prüfenden Produktes eingepflegt ist, befinden sich noch zwei weitere wichtige Dateien. Erstens die Pipeline-Settings.json, die für das Aufrufen der Pipeline relevant ist und ihr die wichtigsten Einstellungen für die Prüfung übergibt. Zweitens der Ordner Pipeline, in welchem die Dateien liegen, die beim Aufrufen der Pipeline abgearbeitet werden sollen – in der Regel sind das mehrere PowerShell-Skripte.

Um dieses Konstrukt noch besser nachvollziehen zu können, stellen Sie sich einfach vor, dass unsere automatische Prüfung ein eigenes „Rezeptbuch“ – nämlich den Ordner Pipeline – besitzt. Die GitHub-Actions erstellen eine virtuelle Umgebung nach den Vorgaben aus dem Workflow und fügen den neuen Code zum bestehenden Code hinzu. Sie geben die Zutat zu unserem Gericht und gleichen mit den Rezepten ab, ob unsere „Code-Speise“ auch „schmecken“, also funktionieren wird.

Diese zusätzliche Prüfung fängt viele Fehler ab, die vielleicht sonst übersehen werden würden und ermöglicht es den Entwickelnden, schnell und umfassend zu reagieren. Des Weiteren können Sie die GitHub-Actions auch vorausschauend einsetzen – zum Beispiel, indem diese regelmäßig den aktuellen Stand der Programmierung gegen eine zukünftige Version prüfen.

Zeitnah reagieren: Nächtliche Kompatibilitätsprüfung von Business Central-Add-ons und PTE-Extensions

Unsere Business Central-Add-ons, die alle in Microsoft AppSource zu finden sind, werden jede Nacht auf ihre Kompatibilität mit dem nächsten Business Central Major Release geprüft. Das Gleiche gilt auch für die Individual-Anpassungen, die wir als geprüfte PTE-Extensions an unsere Kundschaft ausliefern. Dadurch ist es uns möglich, zeitnah auf kommende Änderungen in Business Central zu reagieren – etwa wenn ein Feld oder eine Funktion mit der nächsten Version nicht mehr verfügbar sein wird.

Den Workflow können Sie beliebig erweitern. Er ist in der Lage, neben der oben beschriebenen Prüfung mittels einer Pipeline auch weitere Actions auszuführen. Auf dem GitHub-Marketplace  finden sich viele Actions, die Sie zusätzlich einbauen können.

Integration von Teams-Benachrichtigungen mit Actions, Secrets und Webhooks

Im Folgenden sehen Sie beispielhaft, wie in einem Workflow mithilfe der Action „Notify Teams“ von thechetantalwar  eine Benachrichtigung an Teams integriert wird.

Die Erstellung einer solchen Nachricht besteht aus drei Teilen: einer Action im Workflow, einem Secret im zugehörigen GitHub-Repository und einem Webhook in Microsoft Teams.

Ein Secret bezeichnet eine Art „Geheimfach“ im Repository-Regal. In jedem Regalfach sowie für das gesamte Regal können Sie zu schützende Werte anlegen, welche dann über eine Variable aufgerufen werden. Der tatsächlich hinterlegte Wert ist dann nicht sichtbar, sondern wird erst bei der Ausführung des Codes aufgerufen. Sie können z. B. Passwörter hinterlegen, sodass auch Entwickelnde am Code arbeiten können, denen das Passwort nicht bekannt ist.

Ein Webhook (engl. aus „Web“ und „Hook“ zusammengesetzt; übersetzt in etwa „Web-Haken“) ist die Verbindungsmöglichkeit zu Microsoft Teams. Dabei wird in Teams ein Wert erzeugt, welcher eine Kommunikation zwischen GitHub und Teams herstellt, vorausgesetzt der Webhook ist in GitHub hinterlegt.

Zurück zu unserer Beispiel-Benachrichtigung. Die Action „notify“ ist hierbei ein Job und wird damit auf der gleichen Ebene angesetzt wie der „build“, der die Pipeline „baut“. Sie hat ihre eigenen Steps, die ausgeführt werden.

notify:
    runs-on: ubuntu-latest
    // Das virtuelle Betriebssystem, das für die Ausführung dieses Jobs benötigt wird
    if: failure()
    // Ausführung des Jobs nur dann, wenn im vorhergehenden Job ein Fehler aufgetreten ist
    needs: build
    // Nur wenn der Job „build“ beendet ist, kann „notify“ ausgeführt werden
    steps:
      - name: Notify ms teams
        // Die Bezeichnung kann frei gewählt werden
        uses: thechetantalwar/teams-notify@v2
        // Verweis auf die Action aus dem Marketplace, die genutzt werden soll
        with:
        // Folgende Parameter werden zur Ausführung benötigt
          teams_webhook_url: ${{secrets.TeamsWebhook}}
          // Ein im Repository hinterlegtes Secret, das den Webhook von Teams beinhaltet, also das Gegenstück zu dem die Nachricht gesendet werden soll
          message: "Run of the workflow '${{github.workflow}}' by ${{github.actor}} for ${{github.server_url}}/${{env.repositoryName}}/actions/runs/${{github.run_id}} failed due to an error."
          // Nachricht, die ausgegeben werden soll

Der Bereich, in dem ein Webhook für Teams erstellt wird, befindet sich in dem Kanal, der die Benachrichtigung erhalten soll, und zwar unter Connectors:

Anschließend müssen Sie ein Incoming Webhook hinzufügen und konfigurieren:

Der hier erstellte Webhook wird anschließend als Secret im gewünschten Repository hinterlegt. Es ist auch möglich, ihn als zentrales Secret zu pflegen, wenn Sie aus allen Workflows in allen Repositories Nachrichten in einem bestimmten Kanal sammeln möchten.

Und so sieht die Ausgabe in Microsoft Teams aus:

Die auszugebende Nachricht können Sie relativ frei gestalten. In unserem Beispiel haben wir uns für ein sehr schlichtes Design entschieden, da es uns bei dieser Meldung vor allem um den Informationswert geht und ihre Entwicklung rasch umzusetzen ist.

Teams-Meldung: Direkt von neuen Anpassungen erfahren – auch ohne Zugriff auf GitHub

Eine solche Teams-Meldung ermöglicht es auch Kolleginnen und Kollegen ohne Zugriff auf GitHub eine Rückmeldung zu erhalten, dass eine Anpassung zur nächsten Version ansteht. Sie können somit zeitnah mit Entwickelnden besprechen, wie mit dem „angekündigten Fehler“ umzugehen ist. Und das lange bevor dringender Handlungsbedarf besteht. Allein eine solch kleine Benachrichtigung bedeutet bereits einen zeitlichen Puffer, Handlungsfreiheit und damit am Ende auch bares Geld.

GitHub-Actions: Sichere, hochwertige und performante Code-Speisen entwickeln – und dabei Zeit sparen

Alles in allem stellen GitHub-Actions eine große Bereicherung für die Entwicklung stabiler Software-Produkte dar. Sie sparen den Beteiligten Zeit und ergänzen die Code-Sicherung durch die Entwickelnden um automatisierte Tests und Actions wie der Benachrichtigung via Microsoft Teams. Sie ermöglichen es den Entwickelnden damit, ihren Fokus darauf zu legen, dass der produzierte Code hochwertig, performant und up to date ist.

Und sie ermöglichen noch viel mehr: So haben Sie die Möglichkeit, mit GitHub-Actions gleichzeitig unterschiedliche virtuelle Betriebssysteme für Ihre Code-Prüfungen zu nutzen. Außerdem können Sie die Codes gegen anstehende Versionen testen und eigene Actions bauen , die exakt an Ihre Bedürfnisse angepasst sind.

Die GitHub-Actions können mit den unterschiedlichsten Programmiersprachen – wie Node.js, Python, Java, Ruby, PHP, Go, Rust, .NET etc. – umgehen. Der GitHub-Marketplace  bietet eine riesige Menge hilfreicher Actions. Dort finden Sie für nahezu jede Herausforderung eine passende Action.

In unserer AGOLUTION-Küche sind die GitHub-Actions somit nicht bloß ein weiteres, eigentlich überflüssiges Küchengerät, das irgendwo in der hintersten Ecke verstaubt, weil es nur dreimal im Jahr gebraucht wird. Sie sind – ähnlich wie ein Thermomix – eine integrale Erweiterung und Aufwertung und vereinfachen sowie optimieren das tagtägliche „Code-Kochen“. Damit tragen sie am Ende einen großen Teil zu schmackhaften Gerichten bzw. zu sichereren Software-Produkten bei.