Ajouter des phases, des dépendances, & des conditions

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Une étape est une limite logique dans un pipeline Azure DevOps. Les étapes peuvent être utilisées pour regrouper des actions dans votre processus de développement logiciel (par exemple, construire l'application, exécuter les tests, déployer en pré-production). Chaque index contient un ou plusieurs travaux.

Lorsque vous définissez plusieurs index dans un pipeline, par défaut, ceux-ci s’exécutent l’un après l’autre. Les étapes peuvent également être interdépendantes. Vous pouvez utiliser le mot-clé dependsOn pour définir des dépendances. Les étapes peuvent également être exécutées de manière conditionnelle en fonction du résultat d'une étape précédente.

Pour comprendre le fonctionnement des index avec des travaux parallèles et des licences, consultez Configurer et payer des travaux parallèles.

Pour comprendre le lien entre les index et d’autres parties d’un pipeline, telles que des travaux, consultez Concepts clés des pipelines.

Vous pouvez également en savoir plus sur le lien entre les index et les parties d’un pipeline dans l’article relatif aux index de schéma YAML.

YAML

Vous pouvez organiser les travaux de pipeline en phases. Les phases sont les principales divisions d’un pipeline : « générer cette application », « exécuter ces tests » et « déployer en préproduction » sont de bons exemples de phases. Il s’agit de limites logiques dans votre pipeline qui vous permettent de suspendre le pipeline et d’effectuer diverses vérifications.

Chaque pipeline comporte au moins un index, même si vous ne le définissez pas explicitement. Vous pouvez également organiser des index dans un graphique de dépendance afin qu’un index s’exécute avant un autre. Il y a une limite de 256 tâches par étape.

Classique

Organisez les tâches de déploiement de votre pipeline de publication en étapes. Les étapes sont les principales divisions de votre pipeline de publication : Exécuter les tests fonctionnels, Déployer en préproduction et Déployer en production sont de bons exemples d'étapes de déploiement.

Un index dans un pipeline de mise en production se compose de travaux et de tâches.

Approbations et portes, déclencheurs et conditions de déploiement, et contrôle des stratégies de mise en file d’attente lorsqu’une mise en production est déployée dans un index.

Spécifier des index

YAML

Dans le cas le plus simple, vous n’avez pas besoin de limites logiques dans votre pipeline. Dans ce cas, vous n’avez pas besoin d’utiliser explicitement le mot clé stage. Vous pouvez spécifier directement les travaux dans votre fichier YAML.

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

Si vous organisez votre pipeline en plusieurs index, utilisez le mot clé stages.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

Si vous choisissez de spécifier un pool au niveau de l'étape, tous les travaux définis dans cette étape utilisent ce pool, sauf si vous le spécifiez au niveau du travail.

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

La syntaxe complète pour spécifier un index est la suivante :

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

Classique

Pour ajouter un index à votre pipeline de mise en production, sélectionnez le pipeline de mise en production sur la page Mises en production, sélectionnez l’action pour le modifier, puis sélectionnez l’onglet Pipeline. Bien que la partie la plus importante de la définition d’un index concerne les tâches d’automatisation, vous pouvez également configurer plusieurs propriétés et options pour un index dans un pipeline de mise en production. Vous pouvez :

• Modifiez le nom de l’index ici, si nécessaire.
• Désignez un utilisateur ou un groupe en tant que propriétaire de l’index. Les propriétaires d’index sont avertis chaque fois qu’un déploiement échoue dans cet index. Le statut de propriétaire d’index ne confère pas automatiquement d’autorisations.
• Supprimez l’index du pipeline.
• Modifiez l’ordre des index.
• Enregistrez une copie de l’index en tant que modèle d’index.
• Gérez les paramètres de sécurité de l’index.

Spécifier des dépendances

YAML

Lorsque vous définissez plusieurs index dans un pipeline, par défaut, ils s’exécutent de manière séquentielle dans l’ordre dans lequel vous les définissez dans le fichier YAML, sauf lorsque vous ajoutez des dépendances. En cas de dépendances, les index s’exécutent dans l’ordre des exigences dependsOn.

Les pipelines doivent contenir au moins un index sans dépendances.

La syntaxe pour définir plusieurs index et leurs dépendances est la suivante :

stages:
- stage: string
  dependsOn: string
  condition: string

Exemples d’index qui s’exécutent séquentiellement :

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

Exemples d’index qui s’exécutent en parallèle :

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

Exemple de distribution ramifiée et de distribution non ramifiée :

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    # this stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # this stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # this stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

Classique

Vous contrôlez les dépendances en définissant les déclencheurs sur chaque index du pipeline de mise en production :

• Les index s’exécutent par le biais d’un déclencheur ou en étant démarrés manuellement.
• Avec un déclencheur de post-lancement, une étape démarre dès le début du lancement, en parallèle avec d'autres étapes qui ont des déclencheurs de post-lancement.
• Avec un déclencheur Après l’index, un index démarre après que tous les index dépendants sont terminés. Vous pouvez ainsi modéliser un comportement de distribution ramifiée et non ramifiée pour les index.

Définir les conditions

Vous pouvez spécifier les conditions dans lesquelles chaque index s’exécute avec des expressions. Par défaut, un index s’exécute s’il ne dépend d’aucun autre index, ou si tous les index dont il dépend sont terminés et réussis. Vous pouvez personnaliser ce comportement en forçant l’exécution d’un index même si un index précédent échoue ou en spécifiant une condition personnalisée.

Si vous personnalisez la condition par défaut des étapes précédentes pour un index, vous supprimez les conditions d’achèvement et de réussite. Par conséquent, si vous utilisez une condition personnalisée, il est courant d’utiliser and(succeeded(),custom_condition) pour vérifier si l’index précédent s’est exécuté correctement. Sinon, l’index s’exécute indépendamment du résultat de l’index précédent.

Notes

Les conditions d’échec (« JOBNAME/STAGENAME ») et de réussite (« JOBNAME/STAGENAME ») telles qu’indiquées dans l’exemple suivant fonctionnent uniquement pour les pipelines YAML.

YAML

Exemple d’exécution d’un index en fonction de l’état d’exécution d’un index précédent :

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

Exemple d’utilisation d’une condition personnalisée :

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

Classique

Lorsque vous spécifiez des déclencheurs Après la mise en production ou Après l’index, vous pouvez également spécifier les filtres de branche pour les artefacts consommés lors de la mise en production. Les mises en production sont uniquement déployées dans un index lorsque les filtres de branche sont satisfaits.

Spécifier des stratégies de mise en file d’attente

YAML

Les pipelines YAML ne prennent pas en charge les stratégies de mise en file d’attente. Chaque exécution d’un pipeline est indépendante et ignore les autres exécutions. En d’autres termes, vos deux validations successives peuvent déclencher deux pipelines, et les deux exécutent la même séquence d’index sans s’attendre. Bien que nous travaillons à intégrer des stratégies de mise en file d’attente aux pipelines YAML, nous vous recommandons d’utiliser des approbations manuelles pour séquencer et contrôler manuellement l’ordre d’exécution, si cela est important.

Classique

Dans certains cas, vous pouvez générer des builds plus rapidement qu’elles peuvent être déployées. Vous pouvez également configurer plusieurs agents et, par exemple, créer des mises en production à partir du même pipeline de mise en production pour le déploiement de différents artefacts. Dans ce cas, il est utile de pouvoir contrôler la façon dont plusieurs mises en production sont mises en file d’attente dans un index. Les stratégies de mise en file d’attente vous confèrent ce contrôle.

Les options disponibles pour une stratégie de mise en file d’attente sont les suivantes :

• Nombre de déploiements parallèles : utilisez cette option si vous approvisionnez dynamiquement de nouvelles ressources dans votre index et que ce dernier est physiquement capable de gérer le déploiement de plusieurs mises en production en parallèle, mais que vous souhaitez limiter le nombre de déploiements parallèles.

• Si vous spécifiez un nombre maximal de déploiements, deux autres options s’affichent :

  • Déployer tout en séquence : utilisez cette option si vous souhaitez déployer toutes les mises en production de manière séquentielle dans les mêmes ressources physiques partagées. En déployant les builds l’une après l’autre, vous vous assurez que deux travaux de déploiement ne ciblent pas simultanément les mêmes ressources physiques, même si plusieurs agents de génération et de mise en production sont disponibles. Vous vous assurez également que les requêtes d'approbation préalables au déploiement pour l'étape sont envoyées dans l'ordre.

  • Déployer la dernière et annuler les autres : utilisez cette option si vous produisez des builds plus rapides que des mises en production, et que vous souhaitez uniquement déployer la dernière build.

Pour comprendre le fonctionnement de ces options, envisagez un scénario dans lequel les mises en production R1, R2, …, R5 d’un pipeline de mise en production unique sont créées en succession rapide. Par exemple, supposons que la première étape de ce pipeline soit nommée QA et que des approbateurs pré-déploiement et post-déploiement soient définis.

• Si vous ne spécifiez pas de limite au nombre de déploiements simultanés, les cinq requêtes d'approbation seront envoyées dès que les versions seront créées. Si les approbateurs approuvent toutes les mises en production, elles sont toutes déployées dans l’index AQ en parallèle. (Si l'étape de contrôle qualité n'a pas défini d'approbateurs de pré-déploiement, les cinq versions sont automatiquement déployées en parallèle avec cette étape).

• Si vous spécifiez une limite et que vous déployez tout en séquence, et que la limite a déjà été atteinte, l'approbation de prédéploiement pour la version R1 est envoyée en premier. Une fois cette approbation terminée, le déploiement de la mise en production R1 dans l’index AQ commence. Ensuite, une demande d’approbation de postdéploiement est envoyée pour la mise en production R1. Ce n'est qu'après l'approbation post-déploiement que l'exécution de la version R2 commence et que l'approbation pré-déploiement est envoyée. Le processus se poursuit de cette manière pour toutes les versions dans l'ordre.

• Si vous spécifiez une limite, Déployez le dernier et annulez les autres, et que la limite a déjà été atteinte, les versions R2, R3 et R4 sont ignorées, et l'approbation préalable au déploiement de R5 dans QA est envoyée immédiatement après l'approbation post-déploiement de la version R1.

Spécifier des approbations

YAML

Vous pouvez contrôler manuellement le moment auquel un index doit s’exécuter à l’aide de vérifications d’approbation. Cette vérification est couramment utilisée pour contrôler les déploiements dans des environnements de production. Les vérifications sont un mécanisme à la disposition du propriétaire de ressources qui lui permet de contrôler si un index dans un pipeline peut consommer une ressource et à quel moment. En tant que propriétaire d’une ressource, telle qu’un environnement, vous pouvez définir des vérifications qui doivent être satisfaites pour qu’un index consommant cette ressource puisse démarrer.

Actuellement, les vérifications d’approbation manuelle sont prises en charge sur les environnements. Pour plus d’informations, consultez Approbations.

Classique

Vous pouvez ajouter des approbations manuelles au début ou à la fin de chaque index du pipeline. Pour plus d’informations, consultez Aperçu des portes et des approbations de mise en production.

Ajouter un déclencheur manuel

Les étapes de pipeline YAML déclenchées manuellement vous permettent d’avoir un pipeline unifié sans l’exécuter toujours jusqu’à la fin.

Par exemple, votre pipeline peut inclure des étapes pour la construction, les tests, le déploiement dans un environnement de préproduction et le déploiement en production. Vous pourriez vouloir que toutes les étapes s’exécutent automatiquement, sauf pour le déploiement en production, que vous préférez déclencher manuellement lorsqu’il est prêt.

Pour utiliser cette fonctionnalité, ajoutez la propriété trigger: manual à une étape.

Dans l’exemple suivant, l’étape de développement s’exécute automatiquement, tandis que l’étape de production nécessite un déclenchement manuel. Les deux étapes exécutent un script d’affichage d’un message « hello world ».

stages:
- stage: development
  displayName: Deploy to development
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'
- stage: production
  displayName: Deploy to production
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'

Marquer une étape comme obligatoire

Marquez une étape comme isSkippable: false pour empêcher les utilisateurs du pipeline de passer des étapes. Par exemple, vous pouvez avoir un modèle YAML qui injecte une étape qui effectue une détection de malwares dans tous les pipelines. Si vous définissez isSkippable: false pour cette étape, le Pipeline ne pourra pas passer la détection de malwares.

Dans l’exemple suivant, l’étape de détection de malwares est marquée comme non-skippable, ce qui signifie qu’elle doit être exécutée dans le cadre de l’exécution du pipeline.

- stage: malware_detection
  displayName: Malware detection
  isSkippable: false
  jobs:
  - job: check_job
    ...

Lorsqu’une étape est non-skippable, elle apparaîtra avec une case à cocher désactivée dans le panneau de configuration Étapes à exécuter.