Migrieren von Azure Pipelines zu GitHub Actions

Hinweis

Auf GitHub Enterprise Server gehostete Runner werden aktuell nicht auf GitHub unterstützt.

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 teilen 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 finden Sie unter Grundlegendes zu GitHub Actions.

Wichtige Unterschiede

Berücksichtigen Sie bei der Migration von Azure Pipelines die folgenden Unterschiede:

Azure Pipelines unterstützt einen älteren classic Editor, mit dem Sie Ihre CI-Konfiguration in einem GUI-Editor definieren können, anstatt die Pipelinedefinition in einer YAML-Datei zu erstellen. GitHub Actions verwendet YAML-Dateien, um Workflows zu definieren, und unterstützt keinen grafischen Editor.
mit Azure Pipelines können Sie einige Strukturen in Auftragsdefinitionen 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 die in der YAML-Datei definierten Stages, die zum Erstellen von Bereitstellungs-Workflows verwendet werden können. GitHub Actions erfordert, die Phasen in separate YAML-Workflowdateien aufzuteilen.
Lokale Azure Pipelines Build-Agents können anhand ihrer Eigenschaften 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 finden Sie 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 auftritt, 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 erfordert Azure Pipelines eine explizite Konfiguration, damit der Vorgang bei einem Fehler sofort beendet wird. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions.

Unterschiede in der Standardshell auf 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 verwendet standardmäßig CMD-Syntax

jobs:
  - job: run_command
    pool:
      vmImage: 'windows-latest'
    steps:
      - script: echo "This step runs in CMD on Windows by default"

GitHub Actions-Syntax zur Angabe 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 finden Sie unter Workflowsyntax für GitHub Actions.

Migration von Konditional- und Ausdruckssyntax

Sowohl Azure-Pipelines als auch GitHub Actions können Schritte bedingt ausführen. In Azure Pipelines werden bedingte Ausdrücke mithilfe des Schlüssels condition angegeben. In GitHub Actions werden bedingte Ausdrücke mit dem Schlüssel if angegeben.

Azure Pipelines verwendet Funktionen in Ausdrücken, um Schritte bedingt auszuführen. Im Gegensatz dazu verwendet GitHub Actions eine Infix-Notation. Beispielsweise müssen Sie die funktion eq in Azure Pipelines durch den Operator == in GitHub Actionsersetzen.

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 finden Sie unter Auswerten von Ausdrücken in Workflows und Aktionen.

Abhängigkeiten zwischen Jobs

Sowohl Azure Pipelines als auch GitHub Actions ermöglichen es Ihnen, Abhängigkeiten für einen Job festzulegen. In beiden Systemen laufen Jobs standardmäßig parallel, aber Jobabhängigkeiten können explizit angegeben werden. In Azure Pipelines erfolgt dies mit dem Schlüssel dependsOn. 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 finden Sie unter Workflowsyntax für GitHub Actions.

Aufgaben in Aktionen migrieren

Azure Pipelines verwendet tasks, bei denen es sich um Anwendungskomponenten handelt, 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 finden Sie unter Wiederverwenden von Automatisierungen.

In diesem Artikel