Créer un pipeline avec des étapes
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Dans cet article, découvrez comment créer et exécuter un pipeline YAML plus complexe avec plusieurs étapes et conditions. L'exemple de pipeline comprend des étapes de construction, de test et de déploiement, ainsi que des étapes facultatives pour les déploiements alternatifs et les restaurations. Avec plusieurs étapes, vous pouvez isoler différentes parties de votre pipeline, améliorer le contrôle de qualité et la sécurité, avoir une meilleure visibilité sur la progression du pipeline et atténuer les risques. La phase de restauration vous permet de revenir rapidement à une version stable en cas de problème, d’améliorer la fiabilité et la stabilité.
Ce code fonctionne pour la plupart des scénarios, mais n’inclut pas les exigences spécifiques au langage ou à la plateforme. À l’étape suivante, personnalisez le pipeline pour vos besoins d’implémentation spécifiques.
Conditions préalables
- Un compte GitHub dans lequel vous pouvez créer un référentiel. Créez-en un gratuitement.
- Une organisation et un projet Azure DevOps. Créez-en un gratuitement.
- Possibilité d’exécuter des pipelines sur des agents hébergés par Microsoft. Vous pouvez acheter un travail parallèle ou demander un niveau gratuit.
- Connaissance de base de YAML et d’Azure Pipelines. Pour plus d’informations, veuillez consulter Créez votre premier pipeline.
1. Créer l'étape de construction
À l’étape Build, restaurez les dépendances et exécutez des tests unitaires pour vous assurer que le code est prêt pour les tests et le déploiement. Si votre application doit compiler le code source, procédez ainsi à l’étape de génération.
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
stages:
- stage: Build
displayName: 'Build Stage'
jobs:
- job: BuildJob
displayName: 'Build Job'
steps:
- script: |
echo "Restoring project dependencies..."
displayName: 'Restore dependencies'
- script: |
echo "Running unit tests..."
displayName: 'Run unit tests'
2. Ajouter la phase de test
L’étape Test exécute des tests sur le projet et publie généralement les résultats des tests sur Azure DevOps. Pour en savoir plus sur la publication des résultats des tests, consultez la tâche Publier les résultats des tests.
L'étape de test ne s'exécute que si l'étape de construction se termine avec succès et que l'étape ne peut pas être sautée.
Étant donné que isSkippable est défini sur false, l’option permettant d’ignorer la phase de test n’est pas disponible dans l’interface utilisateur Azure DevOps.
- stage: Test
displayName: 'Test Stage'
dependsOn: Build
isSkippable: false
jobs:
- job: TestJob
displayName: 'Test Job'
steps:
- script: |
echo "Running unit tests..."
displayName: 'Run unit tests'
3. Déployer vers un environnement intermédiaire
La phase DeployToStaging dépend de la phase Test pour fonctionner. Le travail DeployStagingJobWithValidation nécessite une approbation manuelle. La tâche de validation manuelle interrompt l’exécution du pipeline et attend une interaction manuelle. Un utilisateur doit valider la phase avant l’exécution. Une approbation manuelle dans votre pipeline ajoute un autre niveau de sécurité, permet d’atténuer les risques et de s’assurer que toutes les modifications sont examinées par les parties prenantes appropriées.
Le pool pour l'approbation manuelle est server. Les validations manuelles s’exécutent uniquement sur un pool de serveurs.
- stage: DeployToStaging
displayName: 'Deploy to Staging'
dependsOn: Test
jobs:
- job: DeployStagingJob
displayName: 'Deploy to Staging Job'
pool:
vmImage: 'ubuntu-latest'
steps:
- script: |
echo "Build staging job..."
displayName: 'Build and deploy to staging'
- job: DeployStagingJobWithValidation
pool: server
timeoutInMinutes: 4320 # job times out in 3 days
displayName: 'Deploy to Staging Job'
steps:
- task: ManualValidation@1
timeoutInMinutes: 1440 # task times out in 1 day
inputs:
notifyUsers: user@example.com
instructions: 'Please validate the stage configuration and resume'
onTimeout: 'resume'
4. Déployer en production
À l’étape DeployToProduction, l’application se déploie dans l’environnement de production, mais uniquement si l’étape de DeployToStaging réussit et que la branche source est main ou release.
La tâche de validation manuelle ici ajoute une deuxième étape de validation humaine pour le contrôle de sécurité et de qualité. Nous avons également utilisé une tâche de validation manuelle à l’étape DeployToStaging.
- stage: DeployToProduction
displayName: 'Deploy to Production'
dependsOn: DeployToStaging
lockBehavior: sequential
condition: and(succeeded(), in(variables['Build.SourceBranch'], 'refs/heads/main', 'refs/heads/release'))
jobs:
- job: DeployProductionJob
displayName: 'Deploy to Production Job'
steps:
- script: |
echo "Deploying to production..."
# Add your deployment commands here
displayName: 'Run deployment commands'
- job: waitForValidation
displayName: Wait for external validation
pool: server
timeoutInMinutes: 4320 # job times out in 3 days
steps:
- task: ManualValidation@1
timeoutInMinutes: 1440 # task times out in 1 day
inputs:
notifyUsers: user@example.com
instructions: 'Please validate the build configuration and resume'
onTimeout: 'resume'
5. Ajouter des étapes facultatives de production alternative et de retour en arrière
Deux étapes facultatives, DeployToAlternateProduction et Rollback, sont mises en file d’attente manuellement. L’étape DeployToAlternateProduction vous permet d’avoir un environnement de production de sauvegarde prêt au cas où votre environnement principal échoue. Cela améliore la fiabilité et la disponibilité globales de votre application. Vous pouvez également avoir un autre environnement de déploiement pour la récupération d’urgence ou le test et la validation. Pour des stratégies de déploiement plus complexes, voir Travaux de déploiement et Ajouter des étapes, des dépendances et des conditions.
L’étape Rollback fournit un filet de sécurité pour rétablir l’état précédemment stable de votre application en cas de problème pendant ou après un déploiement. Cela peut être dû à un échec de déploiement, à un bogue, à une exigence de conformité, à une récupération d’urgence ou à un autre problème. Une étape de restauration est essentielle pour maintenir la stabilité et la fiabilité de votre application.
- stage: DeployToAlternateProduction
displayName: 'Deploy to Alternate Production'
condition: succeeded()
trigger: manual
jobs:
- job: DeployAlternateProductionJob
displayName: 'Deploy to Alternate Production Job'
steps:
- script: |
echo "Deploying to alternate production..."
# Add your deployment commands here
displayName: 'Run deployment commands'
- stage: Rollback
displayName: 'Rollback Stage'
trigger: manual
jobs:
- job: RollbackJob
displayName: 'Rollback Job'
steps:
- script: |
echo "Rolling back the deployment..."
# Add your rollback commands here
displayName: 'Run rollback commands'