définition de stages.stage

Les phases sont une collection de travaux associés. Par défaut, les phases s’exécutent de manière séquentielle. Chaque étape ne démarre qu’une fois la phase précédente terminée, sauf indication contraire via la dependsOn propriété .

stages:
- stage: string # Required as first property. ID of the stage.
  displayName: string # Human-readable name for the stage.
  pool: string | pool # Pool where jobs in this stage will run unless otherwise specified.
  dependsOn: string | [ string ] # Any stages which must complete before this one.
  condition: string # Evaluate this condition expression to determine whether to run this stage.
  variables: variables | [ variable ] # Stage-specific variables.
  jobs: [ job | deployment | template ] # Jobs which make up the stage.
  lockBehavior: string # Behavior lock requests from this stage should exhibit in relation to other exclusive lock requests.
  templateContext: # Stage related information passed from a pipeline when extending a template.

Définitions qui font référence à cette définition : étapes

Propriétés

stage String. Obligatoire comme première propriété.
ID de la phase.

displayName String.
Nom lisible par l’homme pour la scène.

poolpool.
Pool dans lequel les travaux de cette étape s’exécuteront, sauf indication contraire.

dependsOn string | string list.
Toutes les étapes qui doivent se terminer avant celle-ci. Par défaut, les étapes sont exécutées séquentiellement dans l’ordre défini dans le pipeline. Spécifiez dependsOn: [] pour une étape si elle ne doit pas dépendre de l’étape précédente dans le pipeline.

condition String.
Évaluez cette expression de condition pour déterminer s’il faut exécuter cette étape.

variablesvariables.
Variables spécifiques à la phase.

jobstravaux.
Travaux qui composent la phase.

lockBehavior String.
Les demandes de verrou de comportement de cette étape doivent s’afficher par rapport à d’autres demandes de verrouillage exclusif. séquentiel | runLatest.

templateContext templateContext.
Informations relatives à la phase transmises à partir d’un pipeline lors de l’extension d’un modèle. Pour plus d’informations sur templateContext, consultez Modèles de pipelines YAML étendus peuvent désormais être transmis des informations de contexte pour les étapes, les travaux et les déploiements et modèles - Utiliser templateContext pour passer des propriétés aux modèles.

Notes

Pour plus d’informations sur templateContext, consultez Modèles de pipelines YAML étendus peuvent désormais être transmis des informations de contexte pour les étapes, les travaux et les déploiements et modèles - Utiliser templateContext pour passer des propriétés aux modèles.

Utilisez des vérifications d’approbation pour contrôler manuellement quand une étape doit s’exécuter. Ces vérifications sont couramment utilisées pour contrôler les déploiements dans des environnements de production.

Les vérifications sont un mécanisme disponible pour le propriétaire de la ressource. Elles contrôlent le moment où une phase dans un pipeline consomme une ressource. En tant que propriétaire d’une ressource comme un environnement, vous pouvez définir des vérifications requises avant qu’une étape qui consomme la ressource puisse démarrer.

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

Verrou exclusif

Dans les pipelines YAML, les vérifications sont utilisées pour contrôler l’exécution des phases sur les ressources protégées. L’une des vérifications courantes que vous pouvez utiliser est un verrou exclusif case activée. Cette case activée permet à une seule exécution à partir du pipeline de continuer. Lorsque plusieurs exécutions tentent de déployer dans un environnement en même temps, le case activée annule toutes les anciennes exécutions et autorise le déploiement de la dernière exécution.

Vous pouvez configurer le comportement du verrou exclusif case activée à l’aide de la lockBehavior propriété, qui a deux valeurs :

• runLatest : Seule la dernière exécution acquiert le verrou sur la ressource. Il s’agit de la valeur par défaut si aucune n’est lockBehavior spécifiée.
• sequential : Toutes les exécutions acquièrent séquentiellement le verrou sur la ressource protégée.

L’annulation d’anciennes exécutions est une bonne approche lorsque vos versions sont cumulatives et contiennent toutes les modifications de code des exécutions précédentes. Toutefois, il existe certains pipelines dans lesquels les modifications de code ne sont pas cumulatives. En configurant la lockBehavior propriété, vous pouvez choisir d’autoriser toutes les exécutions à se poursuivre et de les déployer séquentiellement dans un environnement, ou de conserver le comportement précédent d’annulation des anciennes exécutions et d’autoriser uniquement les dernières exécutions. La valeur de sequential implique que toutes les exécutions acquièrent le verrou séquentiellement sur la ressource protégée. La valeur de runLatest implique que seule la dernière exécution acquiert le verrou de la ressource.

Pour utiliser la vérification Verrou exclusif avec des déploiements sequential ou runLatest, suivez ces étapes :

1. Activez la vérification Verrou exclusif sur l’environnement (ou une autre ressource protégée).
2. Dans le fichier YAML du pipeline, spécifiez une nouvelle propriété appelée lockBehavior. Celle-ci peut être spécifiée pour l’ensemble du pipeline ou pour un index donné :

Définie sur un index :

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Définie sur le pipeline :

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Exemples

Cet exemple exécute trois phases, l’une après l’autre. La phase intermédiaire exécute deux travaux en parallèle.

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - script: echo Building!
- stage: Test
  jobs:
  - job: TestOnWindows
    steps:
    - script: echo Testing on Windows!
  - job: TestOnLinux
    steps:
    - script: echo Testing on Linux!
- stage: Deploy
  jobs:
  - job: Deploy
    steps:
    - script: echo Deploying the code!

Cet exemple exécute deux étapes en parallèle. Par souci de concision, les travaux et les étapes sont omis.

stages:
- stage: BuildWin
  displayName: Build for Windows
- stage: BuildMac
  displayName: Build for Mac
  dependsOn: [] # by specifying an empty array, this stage doesn't depend on the stage before it

Voir aussi

En savoir plus sur les étapes, les conditions et les variables.