GitHub ist längst mehr als nur ein Ort, an dem Quellcode gespeichert wird. Mit GitHub Actions lassen sich viele Arbeitsschritte rund um ein Softwareprojekt automatisieren. Das Herzstück davon sind sogenannte Workflows.
Mit einem Workflow kann GitHub zum Beispiel automatisch:
- ein Projekt kompilieren
- Tests ausführen
- Releases erstellen
- Docker-Images bauen
- Anwendungen auf einen Server deployen
- Prüfungen bei Pull Requests durchführen
Gerade bei größeren Projekten sparen solche Automatisierungen viel Zeit und helfen dabei, Fehler frühzeitig zu erkennen.
Was ist ein GitHub Workflow?
Ein Workflow ist ein automatisierter Ablauf innerhalb eines GitHub-Repositories.
Er wird als YAML-Datei im Verzeichnis
.github/workflows/
gespeichert.
Ein Repository kann dabei mehrere Workflows besitzen, zum Beispiel:
.github/
└── workflows/
├── build.yml
├── tests.yml
└── deploy.yml
Jeder Workflow kann dabei eine andere Aufgabe übernehmen.
Ein typisches Beispiel wäre:
Code wird auf GitHub gepusht
↓
Projekt wird gebaut
↓
Tests werden ausgeführt
↓
Anwendung wird veröffentlicht
Damit entsteht eine automatisierte Pipeline.
Der grundsätzliche Aufbau
Ein GitHub Workflow besteht vereinfacht aus mehreren Ebenen:
Event
↓
Workflow
↓
Job
↓
Step
↓
Action oder Befehl
Die wichtigsten Begriffe sind:
| Begriff | Bedeutung |
|---|---|
| Event | Ereignis, das einen Workflow startet |
| Workflow | Gesamter automatisierter Ablauf |
| Job | Teilaufgabe innerhalb eines Workflows |
| Runner | Rechner, auf dem ein Job ausgeführt wird |
| Step | Einzelner Arbeitsschritt |
| Action | Wiederverwendbarer Baustein |
Events: Wann wird ein Workflow gestartet?
Ein Workflow benötigt zunächst einen Auslöser.
Dieser wird innerhalb der YAML-Datei mit on: definiert.
Ein Workflow kann zum Beispiel bei jedem Push gestartet werden:
on:
push:
Oder nur dann, wenn Änderungen auf den main-Branch gepusht werden:
on:
push:
branches:
- main
Auch Pull Requests können einen Workflow auslösen:
on:
pull_request:
Typische Events sind unter anderem:
pushpull_requestworkflow_dispatchschedulerelease
Mit workflow_dispatch lässt sich ein Workflow beispielsweise manuell über die GitHub-Oberfläche starten.
Jobs: Die größeren Arbeitsschritte
Innerhalb eines Workflows werden sogenannte Jobs definiert.
Ein Workflow könnte beispielsweise aus drei Jobs bestehen:
Build
↓
Test
↓
Deploy
Ein Job enthält wiederum mehrere einzelne Arbeitsschritte.
Beispielsweise könnte ein Build-Job:
- den Quellcode herunterladen
- .NET installieren
- Abhängigkeiten laden
- das Projekt kompilieren
Jobs können unabhängig voneinander parallel ausgeführt werden oder voneinander abhängig sein.
Runner: Wo wird der Code ausgeführt?
Jeder Job benötigt einen Runner.
Ein Runner ist der Rechner beziehungsweise die virtuelle Maschine, auf der GitHub die Befehle des Workflows ausführt.
GitHub stellt dafür verschiedene Betriebssysteme bereit.
Zum Beispiel:
runs-on: ubuntu-latest
Für Windows:
runs-on: windows-latest
Oder für macOS:
runs-on: macos-latest
Welcher Runner benötigt wird, hängt vom jeweiligen Projekt ab.
Eine klassische .NET-Webanwendung lässt sich beispielsweise meistens problemlos auf einem Ubuntu-Runner bauen.
Für bestimmte Windows-spezifische Projekte kann dagegen ein Windows-Runner erforderlich sein.
Neben den von GitHub bereitgestellten Runnern können auch eigene Rechner als sogenannte Self-Hosted Runner eingesetzt werden.
Steps: Die einzelnen Arbeitsschritte
Ein Job besteht aus mehreren Steps.
Ein Step kann entweder einen normalen Befehl ausführen oder eine fertige Action verwenden.
Beispielsweise:
steps:
- name: Repository herunterladen
uses: actions/checkout@v4
- name: Projekt bauen
run: dotnet build
Der erste Step verwendet eine fertige Action.
Der zweite Step führt direkt einen Konsolenbefehl aus.
Die Steps werden normalerweise nacheinander abgearbeitet.
Was sind Actions?
Eine Action ist ein wiederverwendbarer Baustein innerhalb eines Workflows.
Eine der am häufigsten verwendeten Actions ist:
uses: actions/checkout@v4
Diese Action lädt den Inhalt des GitHub-Repositories auf den Runner.
Eine weitere typische Action für .NET-Projekte ist:
uses: actions/setup-dotnet@v4
Damit kann auf dem Runner eine bestimmte .NET-Version eingerichtet werden.
Actions können von GitHub selbst, von anderen Entwicklern oder vom eigenen Projekt stammen.
Beispiel: Ein einfacher .NET-Workflow
Ein vollständiger Workflow für ein .NET-Projekt könnte so aussehen:
name: Build and Test
on:
push:
branches:
- main
pull_request:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Repository herunterladen
uses: actions/checkout@v4
- name: .NET installieren
uses: actions/setup-dotnet@v4
with:
dotnet-version: '10.0.x'
- name: Abhängigkeiten laden
run: dotnet restore
- name: Projekt bauen
run: dotnet build --no-restore
- name: Tests ausführen
run: dotnet test --no-build
Dieser Workflow wird automatisch ausgeführt, wenn:
- Code auf den
main-Branch gepusht wird - ein Pull Request gegen
mainerstellt wird
Der Ablauf sieht dann ungefähr so aus:
Push oder Pull Request
↓
Ubuntu-Runner starten
↓
Repository herunterladen
↓
.NET installieren
↓
dotnet restore
↓
dotnet build
↓
dotnet test
Schlägt einer dieser Schritte fehl, wird auch der Workflow als fehlgeschlagen markiert.
Was bedeuten grüne und rote Workflows?
Nach der Ausführung zeigt GitHub den Status eines Workflows an.
Ein grünes Häkchen bedeutet:
✅ Workflow erfolgreich
Ein rotes Symbol bedeutet:
❌ Workflow fehlgeschlagen
Bei einem Fehler kann man den Workflow öffnen und die Ausgabe der einzelnen Steps ansehen.
Dadurch lässt sich relativ schnell erkennen, welcher Befehl oder Test fehlgeschlagen ist.
Continuous Integration mit GitHub Actions
Einer der wichtigsten Anwendungsfälle für Workflows ist Continuous Integration, kurz CI.
Dabei wird bei jeder Änderung automatisch geprüft, ob das Projekt weiterhin funktioniert.
Ein typischer CI-Prozess besteht aus:
Codeänderung
↓
Build
↓
Automatische Tests
↓
Qualitätsprüfung
Dadurch kann beispielsweise verhindert werden, dass fehlerhafter Code unbemerkt in den Hauptbranch übernommen wird.
Gerade bei Projekten mit mehreren Entwicklern ist das sehr hilfreich.
Continuous Deployment
GitHub Actions kann außerdem für Continuous Deployment, kurz CD, verwendet werden.
Dabei wird eine Anwendung nach erfolgreichem Build und erfolgreichen Tests automatisch veröffentlicht.
Ein möglicher Ablauf wäre:
Push auf main
↓
Build
↓
Tests
↓
Docker-Image erstellen
↓
Image veröffentlichen
↓
Server aktualisieren
Damit kann eine Anwendung vollständig automatisiert ausgeliefert werden.
Geheimnisse sicher speichern
Bei Deployments werden häufig Zugangsdaten benötigt, beispielsweise:
- API-Schlüssel
- Passwörter
- SSH-Schlüssel
- Zugangsdaten zu Registries
Solche Daten sollten niemals direkt in einer Workflow-Datei stehen.
GitHub stellt dafür Secrets zur Verfügung.
Ein Secret kann innerhalb eines Workflows beispielsweise so verwendet werden:
${{ secrets.SERVER_PASSWORD }}
Der tatsächliche Wert wird dabei nicht in der YAML-Datei gespeichert.
Workflows und Pull Requests
Workflows sind besonders nützlich in Verbindung mit Pull Requests.
Bevor eine Änderung in den Hauptbranch übernommen wird, kann GitHub automatisch überprüfen:
Pull Request
↓
Build erfolgreich?
↓
Tests erfolgreich?
↓
Codeprüfung bestanden?
↓
Merge erlauben
Damit lassen sich Qualitätskontrollen direkt in den Entwicklungsprozess integrieren.
Typische Einsatzmöglichkeiten
GitHub Workflows können für sehr unterschiedliche Aufgaben verwendet werden.
Dazu gehören unter anderem:
- Anwendungen bauen
- automatisierte Tests durchführen
- Code analysieren
- Docker-Images erstellen
- NuGet-Pakete veröffentlichen
- Releases erstellen
- Dateien generieren
- Webseiten deployen
- Server aktualisieren
- mobile Apps bauen
Workflows sind deshalb nicht nur für große Softwareprojekte interessant.
Auch bei kleinen Projekten können sie viele wiederkehrende Arbeitsschritte automatisieren.
Fazit
GitHub Workflows sind das zentrale Element von GitHub Actions.
Sie ermöglichen es, wiederkehrende Entwicklungs- und Deployment-Prozesse direkt im Repository zu automatisieren.
Der grundlegende Aufbau ist dabei immer ähnlich:
Event
↓
Workflow
↓
Job
↓
Runner
↓
Steps
↓
Actions und Befehle
Für den Einstieg reicht häufig bereits ein einfacher Workflow, der nach jedem Push automatisch das Projekt baut und die vorhandenen Tests ausführt.
Wer dieses Prinzip verstanden hat, kann GitHub Actions anschließend Schritt für Schritt erweitern und daraus komplette CI/CD-Pipelines erstellen.
Gerade in Verbindung mit Branches und Pull Requests werden Workflows zu einem sehr leistungsfähigen Werkzeug, um Software automatisiert zu prüfen, zu bauen und auszuliefern.