Von Azure-Pipelines zu GitHub-Aktionen migrieren

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.

Von Azure-Pipelines zu GitHub-Aktionen migrieren

In diesem Artikel