Von Azure Pipelines zu GitHub Actions: Was es zu beachten gibt

Viele Teams überlegen, ihre CI/CD-Prozesse (Continuous Integration und Delivery) näher an GitHub zu rücken: Repository, Pull Requests und Automation auf einer Plattform zusammenzubringen, die Tool-Landschaft zu vereinfachen und GitHub als zentrale Developer-Plattform zu nutzen. Wer Azure Pipelines kennt, wird in GitHub Actions vieles wiedererkennen: YAML-Syntax, Jobs, Steps, Runner. Doch gleiche Begriffe bedeuten nicht immer das Gleiche, und die Migration ist weniger ein Copy-Paste als ein gezieltes Konzept-Mapping. Dieser Artikel richtet sich an Architekten, DevOps-Ingenieure sowie Entwicklerinnen und Entwickler mit YAML-Hintergrund, die den Wechsel strukturiert angehen wollen.

Von Pipeline zu Workflow: Das mentale Modell übersetzen

Der erste Schritt ist das Übersetzen der bekannten Azure-DevOps-Konzepte in die GitHub-Welt. Eine Azure Pipeline entspricht einem GitHub Workflow. Stages gibt es in GitHub Actions nicht als eigene Ebene: Die Orchestrierung läuft primär über Jobs. Abhängigkeiten zwischen Jobs werden über needs definiert, ähnlich dem dependsOn in Azure Pipelines, aber mit einer anderen Syntax und Semantik. Steps sind in beiden Plattformen vergleichbar.

Die Workflow-Syntax von GitHub Actions und das Azure Pipelines YAML-Schema sind gute Ausgangspunkte für das Mapping. Hilfreich ist es, zuerst das Zielkonzept zu klären und erst danach die Syntax zu migrieren statt umgekehrt.

Trigger, Conditions und Expressions: Ähnlich genug, um gefährlich zu sein

Branch-Filter und Path-Filter gibt es in beiden Plattformen. PR-Ereignisse in GitHub Actions sind enger an GitHub Events gekoppelt: pull_request oder pull_request_target lösen bei Pull-Request-Aktionen aus. Manuelle Ausführungen funktionieren nur, wenn es auch einen workflow_dispatch Trigger gibt. Zusätzlich gibt es noch viele weitere Trigger in GitHub Actions, die es so in Azure Pipelines nicht gibt, wie z.B. Änderung oder Erstellung von Issues oder das Labeln von Pull Requests. Eine Liste aller Trigger findet sich in der GitHub Actions Dokumentation.

Die Ausdruckssyntax unterscheidet sich spürbar. In Azure Pipelines wird zwischen Compile‑/Template‑Expressions (z.B. beim Auswerten von Templates oder Parametern) und Runtime‑Conditions (condition:) unterschieden. GitHub Actions kennt dagegen nur eine Ebene: if‑Ausdrücke, die auf Jobs und Steps angewendet werden. Diese if‑Bedingungen nutzen Kontextobjekte wie needs, env, vars und inputs sowie Funktionen/Expressions wie always(). Wichtig: Ein Job, dessen if‑Bedingung zu false evaluiert, wird in GitHub Actions nicht aus dem Workflow entfernt oder “versteckt”, sondern zur Laufzeit übersprungen (skipped). Beim Übersetzen von Azure‑Conditions sollte jede Bedingung einzeln geprüft und das Verhalten (compile vs. runtime) bewusst nachgebildet werden.

Templates, Reuse und Modularisierung: Gleiches Ziel, andere Werkzeuge

Azure Pipelines kennt YAML-Templates mit Parametern als primäres Wiederverwendungskonzept. GitHub Actions trennt hier stärker: Für ganze Jobs oder vollständige Workflows gibt es Reusable Workflows. Für Step-Gruppen innerhalb eines Jobs gibt es Composite Actions.

Ein wichtiger Unterschied: Reusable Workflows tauchen in der Workflow-Liste als eigenständige Pipeline-Runs auf. Hier ist eine gute Namensgebung wichtig, um die Übersicht zu behalten. Composite Actions hingegen können direkt im .github/actions/-Verzeichnis des gleichen Repositories abgelegt werden, ohne ein separates Repository zu benötigen.

Bei der Migration gilt: Ein Azure-Template, das mehrere Jobs enthält, wird meist zu einem Reusable Workflow. Wiederholte Step-Blöcke innerhalb eines Jobs werden zu einer Composite Action.

Marketplace-Actions: Nutzen, aber mit Bedacht

Ein zentrales Sicherheitsthema beim Einsatz von Marketplace-Actions ist das Versionspinning. Actions verweisen auf einen Git-Tag in einem GitHub-Repository, und dieser Tag kann nachträglich auf einen anderen Commit zeigen. Die empfohlene Praxis ist das Pinnen auf einen SHA-Commit-Hash (einen unveränderlichen, kryptografischen Commit-Fingerabdruck) statt auf einen Tag-Namen:

# Unsicher: Tag kann auf anderen Commit zeigen
- uses: actions/checkout@v4

# Sicher: SHA-Commit-Hash ist unveränderlich
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Nur nichtkritische Third-Party-Actions sollten übernommen werden, wenn Wartung und Vertrauen ausreichend geklärt sind.

Secrets, Permissions und Identity: Sicherheit neu denken

GitHub trennt zwischen Secrets (verschlüsselt, für sensitive Werte), Variables (plaintext, für Konfiguration), Environments im Repository (mit Schutzregeln und Reviewern) und Permissions (Berechtigungen pro Workflow oder Job). Hierbei können Variable und Secrets, sofern berechtigt, innerhalb eines Environments, des Repository oder sogar in der Organisation definiert werden und im Workflow referenziert werden.

Für cloudseitige Authentifizierung empfiehlt GitHub OIDC (OpenID Connect) als bevorzugten Weg. Statt statischer Credentials erstellt OIDC kurzlebige Token, die direkt vom Cloud-Provider ausgestellt werden. Die offizielle Dokumentation zu OIDC in GitHub Actions beschreibt die Konfiguration für Azure, AWS und GCP. Wer also Azure Service Connections in Azure Pipelines hat, sollte prüfen, ob diese durch OIDC ersetzt werden können, um die Sicherheit zu erhöhen und die Verwaltung von Secrets zu reduzieren.

Das automatische GITHUB_TOKEN entspricht dem Job Access Token in Azure Pipelines, aber mit einem anderen Berechtigungsmodell. Der GitHub-Token sollte mit expliziten permissions im Workflow eingeschränkt werden. Hier empfiehlt es sich, mit minimalem Umfang zu beginnen und nur die tatsächlich benötigten Rechte freizugeben:

permissions:
  contents: read    # nur lesen, kein Schreiben ins Repository
  id-token: write   # benötigt für OIDC

Runner, Agents und Execution-Umgebung

Microsoft-hosted Agents und GitHub-hosted Runner sind konzeptuell vergleichbar. GitHub-hosted Runner unterstützen Ubuntu, Windows und macOS. Die Abrechnung erfolgt pro Minute Laufzeit, differenziert nach Betriebssystem und Runner-Größe: Linux ist günstiger als Windows oder macOS.

Ein direktes Äquivalent zu Azure Managed DevOps Pools gibt es in GitHub Actions nicht. Als Alternative eignen sich VM Scale Sets mit Self-hosted Runner, die ähnliche Skalierungsszenarien abdecken. Im Gegensatz zu Azure DevOps gibt es keine separaten Agent-Pool-Limits; die maximale Anzahl paralleler Jobs hängt jedoch vom jeweiligen GitHub-Plan ab (z.B. 20 gleichzeitige Jobs bei Free, bis zu 500 bei Enterprise).

Container Jobs und Service Container gibt es in beiden Plattformen. concurrency in GitHub Actions erlaubt das Gruppieren paralleler Runs und das Abbrechen älterer Läufe, was besonders für Branch- und PR-Workflows hilfreich ist.

Migrationsmuster aus der Praxis: Nicht alles auf einmal umziehen

Eine schrittweise Migration reduziert das Risiko und erlaubt es, Erfahrungen aufzubauen. Ein bewährtes Muster: zuerst Build und Test migrieren, dann Packaging und Artifact-Verwaltung, zuletzt Deployments. Kritische Release-Pipelines können vorerst in Azure Pipelines bleiben.

Beim Umzug gibt es einige technische Unterschiede, die leicht übersehen werden:

• Build-Minuten werden bei GitHub Hosted Runners pro Minute abgerechnet. Das bedeutet, dass ineffiziente Workflows schnell teuer werden können, wenn sie nicht optimiert werden.
• Caching: Schlüsselbasiert und workflow-orientiert; bestehende Azure-Cache-Strategien sollten nicht blind übernommen werden. Auch hier wird für den verbrauchten Speicher bezahlt, nicht wie bei Azure Pipelines.
• Pipeline Artifacts: Artifacts in GitHub werden explizit hochgeladen und heruntergeladen. Sie sind nicht kostenlos: Das enthaltene Kontingent hängt vom GitHub-Plan ab, und der Retention-Zeitraum muss pro Workflow explizit gesetzt werden.

Artifact-Verwaltung verdient besondere Aufmerksamkeit. Überlege für jeden Workflow, was wirklich als Artifact publiziert werden muss. Setze Retention-Zeiträume explizit statt den Default zu übernehmen und plane das manuelle Löschen nicht mehr benötigter Artifacts ein.

Für die Einschätzung der Build‑Dauer lohnt sich ein Blick auf das GitHub Action Importer Tool. Es kann Azure Pipelines YAML automatisiert in GitHub Actions übersetzen und liefert aus der Analyse eine Schätzung der Build‑Zeit und damit eine Abschätzung der zu erwartenden Kosten.

GitHub Actions und Azure Pipelines im Vergleich

GitHub Actions bringt klare Stärken mit: Die native Nähe zu Issues, Pull Requests, Code Owners und Repository Events; Reusable Workflows und Composite Actions als leichtgewichtige Modularisierung; Ein starkes Community-Ökosystem im Marketplace; und OIDC als modernes Identity-Modell.

Zunehmend relevant werden KI-gestützte Automationen in GitHub Actions, die per Prompt gesteuert werden, sogenannte Agentic Workflows, die über die reine CI/CD-Automatisierung hinausgehen. Diese sind nicht für reguläre Build/Deploy-Workflows gedacht, sondern für Aufgaben mit generativer KI (GenAI): Issue-Triage, automatische Paket-Updates mit Berücksichtigung von Migrationspfaden und Breaking Changes, oder KI-gestützte Code-Reviews. Wer diesen Bereich erkundet, sollte klassische CI/CD-Workflows und Agentic Workflows klar trennen.

Azure Pipelines hat weiterhin Vorteile dort, wo Teams tief in die Azure DevOps Suite eingebunden sind: Boards, Test Plans, Artifacts und etablierte Unternehmensprozesse rund um Agent-Pools und Freigabeworkflows. Für manche Teams ist ein bewusster Hybridbetrieb deshalb die pragmatischere Entscheidung.

Mit einem sauberen Startbild in GitHub Actions

GitHub Actions und Azure Pipelines verfolgen die gleichen CI/CD-Ziele, folgen aber einer anderen Plattformlogik. Die Migration gelingt besser über Konzepte als über Syntax-Kopie: Erst das Zielmodell verstehen, dann die YAML-Syntax übersetzen.

Als Einstiegspunkt empfiehlt sich ein kleiner CI-Workflow für einen bestehenden Build. Reusable Workflows und Composite Actions sollten früh definiert werden, um Wiederholungen zu vermeiden. Permissions von Anfang an minimieren und OIDC bevorzugen, wo es möglich ist. Migrationsentscheidungen, besonders wo und warum bewusst von Azure Pipelines abgewichen wird, lohnt es sich zu dokumentieren.

Wie gehst du die Migration an: Vollständiger Wechsel oder Hybridbetrieb? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.