Note
Auf GitHub gehostete Runner werden aktuell nicht auf GitHub Enterprise Server unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.
Einführung
Azure-Pipelines und GitHub Actions ermöglichen es Dir, Workflows zu erstellen, die automatisch Code bauen, testen, publizieren, freigeben und bereitstellen. Azure-Pipelines und GitHub Actions haben einige Ähnlichkeiten in der Workflow-Konfiguration:
- Workflow-Konfigurationsdateien werden in YAML geschrieben und im Code-Repository gespeichert.
- Workflows umfassen einen oder mehrere Jobs.
- Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.
- Schritte oder Aufgaben können wiederverwendet und in der Community gemeinsam genutzt werden.
Weitere Informationen findest du unter Grundlegendes zu GitHub Actions.
Wichtige Unterschiede
Bei der Migration von Azure-Pipelines sollten die folgenden Unterschiede beachtet werden:
- Azure Pipelines unterstützt einen veralteten klassischen Editor, mit dem du deine CI-Konfiguration in einem GUI-Editor definieren kannst, anstatt die Pipelinedefinition in einer YAML-Datei zu erstellen. GitHub Actions verwendet YAML-Dateien, um Workflows zu definieren, und unterstützt keinen grafischen Editor.
- Azure Pipelines erlaubt Dir, einige Strukturen in Job-Definitionen zu weglassen. Wenn Du zum Beispiel nur einen einzigen Job hast, brauchst Du den Job an sich nicht zu definieren, sondern nur seine Schritte. GitHub Actions erfordert eine explizite Konfiguration und die YAML-Struktur kann nicht weggelassen werden.
- Azure Pipelines unterstützt Phasen, die in der YAML-Datei definiert sind und zum Erstellen von Bereitstellungsworkflows verwendet werden können. GitHub Actions erfordert, die Phasen in separate YAML-Workflowdateien zu aufzuteilen.
- Bei Azure-Pipelines können lokale Build-Agenten nach Funktionalität ausgewählt werden. Bei GitHub Actions können selbst-gehostete Runner nach Labels ausgewählt werden.
Jobs und Schritte migrieren
Jobs und Schritte in Azure-Pipelines sind sehr ähnlich zu Jobs und Schritten in GitHub Actions. In beiden Systemen haben Jobs folgende Merkmale:
- Jobs enthalten eine Reihe von Schritten, die nacheinander ausgeführt werden.
- Jobs laufen auf separaten virtuellen Maschinen oder in separaten Containern.
- Jobs werden standardmäßig parallel ausgeführt, können aber so konfiguriert werden, dass sie sequentiell laufen.
Skriptschritte migrieren
Du kannst in einem Workflow ein Skript oder einen Shell-Befehl als Schritt ausführen. In Azure Pipelines können Skriptschritte mit dem Schlüssel script
oder mit den Schlüsseln bash
, powershell
oder pwsh
angegeben werden. Skripts können außerdem als Eingabe für die Bash-Aufgabe oder die PowerShell-Aufgabe angegeben werden.
In GitHub Actions sind alle Skripts mit dem Schlüssel run
spezifiziert. Um eine bestimmte Shell auszuwählen, kannst du bei der Bereitstellung des Skripts den Schlüssel shell
angeben. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
Nachfolgend ein Beispiel für die Syntax in jedem System.
Azure Pipelines-Syntax für Skriptschritte
jobs:
- job: scripts
pool:
vmImage: 'windows-latest'
steps:
- script: echo "This step runs in the default shell"
- bash: echo "This step runs in bash"
- pwsh: Write-Host "This step runs in PowerShell Core"
- task: PowerShell@2
inputs:
script: Write-Host "This step runs in PowerShell"
GitHub Actions-Syntax für Skriptschritte
jobs:
scripts:
runs-on: windows-latest
steps:
- run: echo "This step runs in the default shell"
- run: echo "This step runs in bash"
shell: bash
- run: Write-Host "This step runs in PowerShell Core"
shell: pwsh
- run: Write-Host "This step runs in PowerShell"
shell: powershell
Unterschiede in der Behandlung von Skriptfehlern
In Azure Pipelines können Skripts so konfiguriert werden, dass ein Fehler ausgegeben wird, wenn eine Ausgabe an stderr
gesendet wird. GitHub Actions unterstützt diese Konfiguration nicht.
GitHub Actions konfiguriert Shells zum "schnellen Scheitern" wann immer möglich , was das Skript sofort beendet, wenn einer der Befehle in einem Skript mit einem Fehlercode endet. Im Gegensatz dazu erfordern Azure-Pipelines explizite Konfiguration, um bei einem Fehler sofort abzubrechen. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
Unterschiede in der Standard-Shell unter Windows
In Azure Pipelines ist die Standardshell für Skripts auf Windows-Plattformen die Befehlsshell (cmd.exe). In GitHub Actions ist die Standard-Shell für Skripte auf Windows-Plattformen die PowerShell. PowerShell hat mehrere Unterschiede in internen Befehlen, Auswertung von Variablen und Flusssteuerung.
Wenn Du einen einfachen Befehl ausführst, kannst Du in PowerShell möglicherweise ein Skript der Command Shell ohne Änderungen laufen lassen. Aber in den meisten Fällen musst Du entweder Dein Skript zur Syntax der PowerShell aktualisieren oder GitHub Actions anweisen, das Skript mit der Command Shell statt mit PowerShell auszuführen. Dazu kannst du shell
als cmd
angeben.
Nachfolgend ein Beispiel für die Syntax in jedem System.
Azure Pipelines-Syntax, die standardmäßig CMD verwendet
jobs:
- job: run_command
pool:
vmImage: 'windows-latest'
steps:
- script: echo "This step runs in CMD on Windows by default"
GitHub Actions-Syntax zum Angeben von CMD
jobs:
run_command:
runs-on: windows-latest
steps:
- run: echo "This step runs in PowerShell on Windows by default"
- run: echo "This step runs in CMD on Windows explicitly"
shell: cmd
Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
Syntax für Bedingungen und Ausdrücke migrieren
Sowohl Azure-Pipelines als auch GitHub Actions können Schritte bedingt ausführen. In Azure Pipelines werden bedingte Ausdrücke mit dem Schlüssel condition
angegeben. In GitHub Actions werden bedingte Ausdrücke mit dem Schlüssel if
angegeben.
Azure-Pipelines verwenden Funktionen innerhalb von Ausdrücken, um Schritte bedingt auszuführen. Im Gegensatz dazu verwenden GitHub Actions eine Infix-Notation. Zum Beispiel musst du die Funktion eq
in Azure Pipelines in GitHub Actions durch den Operator ==
ersetzen.
Nachfolgend ein Beispiel für die Syntax in jedem System.
Azure Pipelines-Syntax für bedingte Ausdrücke
jobs:
- job: conditional
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "This step runs with str equals 'ABC' and num equals 123"
condition: and(eq(variables.str, 'ABC'), eq(variables.num, 123))
GitHub Actions-Syntax für bedingte Ausdrücke
jobs:
conditional:
runs-on: ubuntu-latest
steps:
- run: echo "This step runs with str equals 'ABC' and num equals 123"
if: ${{ env.str == 'ABC' && env.num == 123 }}
Weitere Informationen findest du unter Auswerten von Ausdrücken in Workflows und Aktionen.
Abhängigkeiten zwischen Jobs
Sowohl bei Azure-Pipelines als auch bei GitHub Actions kannst Du Abhängigkeiten für einen Job festlegen. In beiden Systemen laufen Jobs standardmäßig parallel, aber Jobabhängigkeiten können explizit angegeben werden. In Azure Pipelines wird dies mit dem Schlüssel dependsOn
gemacht. In GitHub Actions wird dafür der Schlüssel needs
verwendet.
Nachfolgend ein Beispiel für die Syntax in jedem System. Die Workflows starten einen ersten Auftrag namens initial
, und wenn dieser abgeschlossen ist, werden zwei Aufträge namens fanout1
und fanout2
ausgeführt. Wenn diese Aufträge abgeschlossen sind, wird der Auftrag fanin
ausgeführt.
Azure Pipelines-Syntax für Abhängigkeiten zwischen Aufträgen
jobs:
- job: initial
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "This job will be run first."
- job: fanout1
pool:
vmImage: 'ubuntu-latest'
dependsOn: initial
steps:
- script: echo "This job will run after the initial job, in parallel with fanout2."
- job: fanout2
pool:
vmImage: 'ubuntu-latest'
dependsOn: initial
steps:
- script: echo "This job will run after the initial job, in parallel with fanout1."
- job: fanin:
pool:
vmImage: 'ubuntu-latest'
dependsOn: [fanout1, fanout2]
steps:
- script: echo "This job will run after fanout1 and fanout2 have finished."
GitHub Actions-Syntax für Abhängigkeiten zwischen Aufträgen
jobs:
initial:
runs-on: ubuntu-latest
steps:
- run: echo "This job will be run first."
fanout1:
runs-on: ubuntu-latest
needs: initial
steps:
- run: echo "This job will run after the initial job, in parallel with fanout2."
fanout2:
runs-on: ubuntu-latest
needs: initial
steps:
- run: echo "This job will run after the initial job, in parallel with fanout1."
fanin:
runs-on: ubuntu-latest
needs: [fanout1, fanout2]
steps:
- run: echo "This job will run after fanout1 and fanout2 have finished."
Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
„Tasks“ (Aufgaben) zu Aktionen migrieren
Azure Pipelines verwendet Aufgaben. Hierbei handelt es sich um Anwendungskomponenten, die in mehreren Workflows wiederverwendet werden können. GitHub Actions verwendet Aktionen, mit denen du Aufgaben ausführen und deinen Workflow anpassen kannst. In beiden Systemen kannst Du den Namen der zu ausführenden Aufgabe oder Aktion sowie alle erforderlichen Eingaben als Schlüssel/Wert-Paare angeben.
Nachfolgend ein Beispiel für die Syntax in jedem System.
Azure Pipelines-Syntax für Aufgaben
jobs:
- job: run_python
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.7'
architecture: 'x64'
- script: python script.py
GitHub Actions-Syntax für Aktionen
jobs:
run_python:
runs-on: ubuntu-latest
steps:
- uses: actions/setup-python@v5
with:
python-version: '3.7'
architecture: 'x64'
- run: python script.py
Aktionen, die du in deinem Workflow verwenden kannst, findest du in GitHub Marketplace, oder du kannst deine eigenen Aktionen erstellen. Weitere Informationen findest du unter Freigeben von Automatisierungen.