Die Nordlicht Reisen GmbH hat ihr Buchungsportal in einem GitHub-Repository. Das Team, das die Zahlungsanbindung pflegt, arbeitet dagegen mit Boards und Pipelines in Azure DevOps und möchte seine Builds dort lassen. Sie sollen entscheiden, welches Werkzeug die Auslieferung des Portals übernimmt, das Repository mit Azure Pipelines verbinden und festlegen, wann welche Pipeline startet. Das sind die Fähigkeiten dieser Lektion: eine Lösung zur Automatisierung der Bereitstellung auswählen, GitHub-Repositories mit Azure Pipelines verbinden und Trigger-Regeln für Pipelines schreiben.
Vorwissen: Wie ein Workflow in GitHub Actions aufgebaut ist, steht in K3, Lektion 3.7.1. Wie eine YAML-Pipeline in Azure Pipelines für ein GitHub-Repository entsteht, mit Agent, Vorlage und Variablengruppe, steht in K3, Lektion 3.7.2. Dort bauen Sie jeweils einen Weg. Diese Lektion beginnt eine Ebene darüber: Sie wählen zwischen den Wegen, binden die Welten aneinander und steuern, wann ein Lauf startet.
Eine Lösung auswählen
Was die beiden Werkzeuge gemeinsam haben
Beide bauen, testen und liefern aus, beide lesen eine YAML-Datei aus dem Repository, beide kennen Jobs, Schritte, Variablen, Geheimnisse und Wiederverwendung. Deshalb ist die Frage selten „was kann das eine, was das andere nicht kann“. Die Frage lautet: Wo liegen Code, Menschen und Rechte schon, und was kostet der Wechsel?
Die Anleitung von GitHub zur Migration von Azure Pipelines nach GitHub Actions nennt, wo sich die Werkzeuge unterscheiden:
| Thema | Azure Pipelines | GitHub Actions |
|---|---|---|
| Editor | daneben gibt es den klassischen grafischen Editor | laut GitHub „does not support a graphical editor“ |
| Stufen | Schlüsselwort stages in einer Datei |
laut GitHub müssen Stufen in getrennte Workflow-Dateien (Aufbau mit mehreren Jobs und needs siehe Lektion 4.3) |
| Reihenfolge von Jobs | dependsOn |
needs |
| Bedingungen | condition mit Funktionen wie eq() |
if mit Operatoren wie == |
| Skripte | script, bash, pwsh oder Aufgaben-Eingaben |
alle Skripte stehen unter run, die Shell wählt shell |
| Standard-Shell unter Windows | die Eingabeaufforderung cmd.exe | PowerShell |
| Auswahl eines eigenen Rechners | Fähigkeiten (capabilities) des Agents | Labels des Runners |
| Wiederverwendbare Bausteine | Aufgaben (tasks) | Aktionen (actions), gefunden im GitHub Marketplace |
Zwei Zeilen daraus tragen Entscheidungen. Wer die Stufen und Prüfungen einer Auslieferung in einer Datei sehen will, findet in Azure Pipelines das Schlüsselwort dafür. Wer eine Pipeline portiert, muss beachten, dass Azure Pipelines bei einem Schreibzugriff auf stderr scheitern kann, GitHub dies laut der Anleitung aber nicht unterstützt, und dass die Standard-Shell unter Windows eine andere ist.
Kombinieren statt entscheiden
Sie müssen nicht ein Werkzeug für alles wählen. Microsoft beschreibt zur Aktion Azure/pipelines als Beispiel, GitHub Actions für die kontinuierliche Integration und Azure Pipelines für die kontinuierliche Bereitstellung zu nutzen, um Funktionen wie Freigaben, Umgebungen und die enge Anbindung an Kubernetes zu verwenden. Die Aktion startet aus einem Workflow heraus eine Pipeline in Azure DevOps; sie nimmt laut ihrer Seite die Projekt-URL, den Namen der Pipeline und einen persönlichen Zugriffstoken (PAT) der Organisation als Eingaben. Das Beispiel steht im Abschnitt „Beide Welten verbinden“.
Die Kriterien
Fünf Fragen ordnen eine Entscheidung. Jede Antwort ist eine Beobachtung über Ihr Team, keine Eigenschaft eines Werkzeugs:
- Wo liegt der Code? Liegt er bei GitHub, sind Pull Request, Prüfungen und Workflow an einem Ort. Liegt er in Azure Repos, bleibt das Ergebnis der Pipeline an denselben Rechten und Work Items.
- Wer pflegt Prüfungen und Freigaben? Umgebungen mit Prüfungen und Freigaben sind Thema der Lektion 4.7; sie arbeiten in Azure Pipelines in YAML, bei GitHub über Umgebungen mit Schutzregeln.
- Wie viel Rechenzeit braucht der Lauf, und wer zahlt sie? Die Modelle unterscheiden sich (Lektion 4.2).
- Welche Bausteine brauchen Sie? Aufgaben für Azure Pipelines, Aktionen für GitHub Actions: Prüfen Sie, ob beide Seiten Ihre Ziele abdecken.
- Welche Verwaltung besteht schon? Organisationen, Berechtigungen und Pools sind in beiden Welten getrennt zu pflegen (Modul D5).