Introduction
Azure Pipelines et GitHub Actions vous permettent de créer automatiquement des flux de travail qui créent, testent, publient, publient et déploient du code. Azure Pipelines et GitHub Actions partagent certaines similitudes dans la configuration du flux de travail :
- Les fichiers de configuration de workflow sont écrits en YAML et sont stockés dans le dépôt du code.
- Les workflows comportent un ou plusieurs travaux.
- Les travaux incluent une ou plusieurs étapes ou commandes individuelles.
- Les étapes ou les tâches peuvent être réutilisées et partagées avec la communauté.
Pour plus d’informations, consultez « Présentation des GitHub Actions ».
Différences clés
Lors de la migration à partir de Azure Pipelines, tenez compte des différences suivantes :
- Azure Pipelines prend en charge un éditeur hérité classique, ce qui vous permet de définir votre configuration CI dans un éditeur d’interface graphique utilisateur au lieu de créer la définition de pipeline dans un fichier YAML. GitHub Actions utilise des fichiers YAML pour définir des workflows et ne prend pas en charge un éditeur graphique.
- Azure Pipelines vous permet d’omettre une structure dans les définitions de travaux. Par exemple, si vous n’avez qu’un seul travail, vous n’avez pas besoin de définir le travail, mais uniquement ses étapes. GitHub Actions nécessite une configuration explicite et la structure YAML ne peut pas être omise.
- Azure Pipelines prend en charge stages définis dans le fichier YAML, qui peut être utilisé pour créer des flux de travail de déploiement. GitHub Actions vous oblige à séparer les phases en fichiers de workflow YAML distincts.
- Les agents de build sur site Azure Pipelines peuvent être sélectionnés en fonction de leurs fonctions. Les exécuteurs auto-hébergés GitHub Actions peuvent être sélectionnés avec des étiquettes.
Migration des travaux et des étapes
Les travaux et les étapes de Azure Pipelines sont très similaires aux travaux et aux étapes de GitHub Actions. Dans les deux systèmes, les travaux présentent les caractéristiques suivantes :
- Les travaux contiennent une série d’étapes qui s’exécutent de manière séquentielle.
- Les travaux s’exécutent sur des machines virtuelles distinctes ou dans des conteneurs distincts.
- Les travaux s’exécutent en parallèle par défaut, mais peuvent être configurés pour s’exécuter séquentiellement.
Migration des étapes de script
Vous pouvez exécuter un script ou une commande d’environnement en tant qu’étape dans un workflow. Dans Azure Pipelines, les étapes de script peuvent être spécifiées à l’aide de la clé script ou avec les clés bash, powershell ou pwsh clés. Les scripts peuvent également être spécifiés en tant qu’entrée de la tâche Bash ou de la tâche PowerShell.
Dans GitHub Actions, tous les scripts sont spécifiés à l’aide de la clé run. Pour sélectionner un shell particulier, vous pouvez spécifier la clé shell lors de la fourniture du script. Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».
Voici un exemple de syntaxe pour chaque système.
Syntaxe "Azure Pipelines" pour les étapes de script
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"
Syntaxe GitHub Actions pour les étapes de script
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
Différences dans la gestion des erreurs de script
Dans Azure Pipelines, les scripts peuvent être configurés pour produire une erreur si une sortie est envoyée à stderr. GitHub Actions ne prend pas en charge cette configuration.
GitHub Actions configure les shells pour passer en « mode Fail-fast » dans la mesure du possible, ce qui arrête immédiatement le script si l’une des commandes d’un script se termine avec un code d’erreur. En revanche, Azure Pipelines nécessite une configuration explicite pour se terminer immédiatement en cas d'erreur. Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».
Différences dans l’interpréteur de commandes par défaut sur Windows
Dans Azure Pipelines, l’interpréteur de commandes par défaut pour les scripts sur les plateformes Windows est l’interpréteur de commandes (cmd.exe). Dans GitHub Actions, le shell par défaut pour les scripts sur les plateformes Windows est PowerShell. PowerShell présente plusieurs différences dans les commandes intégrées, l’expansion de variables et le contrôle de flux.
Si vous exécutez une commande simple, vous pouvez exécuter un script d’interface de commande dans PowerShell sans aucune modification. Toutefois, dans la plupart des cas, vous devez mettre à jour votre script avec la syntaxe PowerShell ou demander à GitHub Actions d’exécuter le script avec l’interface de commande au lieu de PowerShell. Pour ce faire, spécifiez shell comme cmd.
Voici un exemple de syntaxe pour chaque système.
syntaxe Azure Pipelines à l’aide de CMD par défaut
jobs:
- job: run_command
pool:
vmImage: 'windows-latest'
steps:
- script: echo "This step runs in CMD on Windows by default"
Syntaxe GitHub Actions pour la spécification de 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
Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».
Migration des conditions et de la syntaxe des expressions
Azure Pipelines et GitHub Actions peuvent exécuter les deux étapes de manière conditionnelle. Dans Azure Pipelines, les expressions conditionnelles sont spécifiées à l’aide de la clé condition. Dans GitHub Actions, les expressions conditionnelles sont spécifiées à l’aide de la clé if.
Azure Pipelines utilise des fonctions dans des expressions pour exécuter des étapes conditionnellement. En revanche, GitHub Actions utilise une notation infixe. Par exemple, vous devez remplacer la fonction eq dans Azure Pipelines par l’opérateur == dans GitHub Actions.
Voici un exemple de syntaxe pour chaque système.
syntaxe Azure Pipelines pour les expressions conditionnelles
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))
Syntaxe GitHub Actions pour les expressions conditionnelles
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 }}
Pour plus d’informations, consultez « Évaluer des expressions dans les workflows et les actions. ».
Dépendances entre les travaux
Les deux Azure Pipelines et GitHub Actions vous permettent de définir des dépendances pour un travail. Dans les deux systèmes, les travaux s’exécutent en parallèle par défaut, mais les dépendances de travaux peuvent être spécifiées explicitement. Dans Azure Pipelines, cela s’effectue avec la clé dependsOn. Dans GitHub Actions, cette opération est effectuée avec la clé needs.
Voici un exemple de syntaxe pour chaque système. Les workflows démarrent un premier travail nommé initialet, une fois ce travail terminé, deux travaux nommés fanout1 et fanout2 s’exécutent. Enfin, une fois ces travaux terminés, le travail fanin s’exécute.
syntaxe Azure Pipelines pour les dépendances entre les tâches
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."
Syntaxe GitHub Actions pour les dépendances entre les tâches
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."
Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».
Migration de tâches vers des actions
Azure Pipelines utilise tasks, qui sont des composants d’application qui peuvent être réutilisés dans plusieurs flux de travail. GitHub Actions utilise des actions qui peuvent être utilisées pour effectuer des tâches et personnaliser votre workflow. Dans les deux systèmes, vous pouvez spécifier le nom de la tâche ou de l’action à exécuter, ainsi que toutes les entrées requises sous forme de paires clé/valeur.
Voici un exemple de syntaxe pour chaque système.
Syntaxe des tâches pour Azure Pipelines
jobs:
- job: run_python
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.7'
architecture: 'x64'
- script: python script.py
Syntaxe GitHub Actions pour les actions
jobs:
run_python:
runs-on: ubuntu-latest
steps:
- uses: actions/setup-python@v5
with:
python-version: '3.7'
architecture: 'x64'
- run: python script.py
Vous pouvez trouver des actions que vous pouvez utiliser dans votre workflow dans GitHub Marketplace, ou vous pouvez créer vos propres actions. Pour plus d’informations, consultez « Réutilisation des automatisations ».