Pipelines de mise en production classiques

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

Les pipelines de mise en production classiques fournissent aux développeurs un cadre pour le déploiement d’applications dans plusieurs environnements de manière efficace et sécurisée. À l’aide de pipelines de mise en production classiques, vous pouvez automatiser les processus de test et de déploiement, configurer des stratégies de déploiement flexibles, incorporer des flux de travail d’approbation et garantir des transitions d’application fluide entre différentes étapes.

Fonctionnement des pipelines de mise en production

Azure Pipelines exécute les étapes suivantes dans le cadre de chaque déploiement :

1. Approbations pré-déploiement :

   Quand une nouvelle demande de déploiement est déclenchée, Azure Pipelines vérifie si une approbation de prédéploiement est nécessaire avant de déployer une mise en production sur une phase. Si une approbation est requise, il envoie des notifications par e-mail aux approbateurs concernés.

2. Mise en file d’attente du travail de déploiement :

   Azure Pipelines planifie le travail de déploiement sur un agent disponible.

3. Sélection de l’agent :

   Un agent disponible récupère le travail de déploiement. Un pipeline de mise en production peut être configuré pour sélectionner dynamiquement un agent approprié pendant l’exécution.

4. Télécharger des artefacts :

   L’agent récupère et télécharge tous les artefacts spécifiés dans la version.

5. Exécuter la tâche de déploiement :

   L’agent exécute toutes les tâches du travail de déploiement.

6. Générer des journaux d’activité de progression :

   L’agent génère des journaux complets pour chaque étape de déploiement et les renvoie à Azure Pipelines.

7. Approbations de postdéploiement :

   Une fois le déploiement terminé, Azure Pipelines vérifie si une approbation post-déploiement est nécessaire pour cette phase particulière. Si aucune approbation n’est nécessaire, ou une fois qu’une approbation requise est obtenue, elle passe à l’étape suivante pour lancer le déploiement.

Modèle de déploiement

Les pipelines de mise en production Azure prennent en charge un large éventail de sources d’artefacts, comme Jenkins, Azure Artifacts et Team City. L’exemple suivant illustre un modèle de déploiement utilisant des pipelines de mise en production Azure :

Dans l’exemple suivant, le pipeline se compose de deux artefacts de build provenant de pipelines de build distincts. L’application est d’abord déployée sur la phase Dev, puis dupliquée sur deux phases AQ. Si le déploiement réussit dans les deux phases AQ, l’application est déployée sur l’anneau de production 1, puis sur l’anneau de production 2. Chaque anneau de production représente plusieurs instances d’une même application Web déployée dans différentes localisations dans le monde.

FAQ

Q : Comment modifier des variables au moment de la mise en production ?

R : Sous l’onglet Variables de votre pipeline de mise en production, cochez l’option Définissable au moment de la mise en production pour les variables que vous voulez modifier quand une mise en production est en file d’attente.

Par la suite, lors de la génération d’une nouvelle version, vous avez la possibilité de modifier les valeurs de ces variables.

Q : Quand serait-il plus approprié de modifier une version au lieu du pipeline qui la définit ?

R : Vous pouvez modifier les approbations, les tâches et les variables d’une instance de mise en production. Toutefois, ces modifications s’appliquent uniquement à cette instance. Si vous voulez que vos changements s’appliquent à toutes les versions ultérieures, modifiez plutôt le pipeline de mise en production.

Q : Quels sont les scénarios où la fonctionnalité « abandonner une version » est utile ?

R : Si vous n’envisagez pas de réutiliser la mise en production, ou si vous ne voulez pas qu’elle soit utilisée, vous pouvez abandonner la mise en production de la façon suivante Pipelines> (...) >Abandonner. Vous ne pouvez pas abandonner une mise en production quand un déploiement est en cours. Vous devez d’abord annuler le déploiement.

Q : Comment gérer les noms des nouvelles mises en production ?

R : La convention d’affectation de noms par défaut pour les pipelines de mise en production est la numérotation séquentielle, où les versions sont nommées Version-1, Version-2, et ainsi de suite. Toutefois, vous avez la possibilité de personnaliser le schéma d’affectation de noms en modifiant le masque de format du nom de version. Dans l’onglet Options de votre pipeline de mise en production, accédez à la page Général et ajustez la propriété de format du nom de version en fonction de vos préférences.

Quand vous spécifiez le masque de format, vous pouvez utiliser les variables prédéfinies suivantes. Exemple : Le format de nom de mise en production suivant : Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName) crée la mise en production suivante : Release 002 for build 20170213.2 MySampleAppBuild.

Variable	Description
Rev: rr	Nombre incrémenté automatiquement avec au moins le nombre de chiffres spécifié.
Date / Date: MMddyy	Date actuelle, au format par défaut MMddyy. Toutes les combinaisons de M/MM/MMM/MMMM, d/dd/ddd/dddd, y/yy/yyyy/yyyy, h/hh/H/HH, m/mm, s/ss sont prises en charge.
System.TeamProject	Nom du projet auquel cette build appartient.
Release.ReleaseId	ID de la mise en production, qui est unique dans toutes les mises en production du projet.
Release.DefinitionName	Nom du pipeline de mise en production auquel la mise en production actuelle appartient.
Build.BuildNumber	Numéro de la build contenue dans la mise en production. Si une mise en production a plusieurs builds, il s’agit du numéro de la build principale.
Build.DefinitionName	Nom de pipeline de la build contenue dans la mise en production. Si une mise en production a plusieurs builds, il s’agit du nom de pipeline de la build principale.
Artifact.ArtifactType	Type de la source d’artefacts liée à la mise en production. Par exemple, il peut s’agir d’Azure Pipelines ou de Jenkins.
Build.SourceBranch	Branche de la source d’artefacts principale. Pour Git, c’est main si la branche est refs/heads/main. Pour Team Foundation Version Control, c’est branch si le chemin de serveur racine de l’espace de travail est $/teamproject/branch. Cette variable n’est pas définie pour Jenkins ou d’autres sources d’artefacts.
Variable personnalisée	Valeur d’une propriété de configuration globale définie dans le pipeline de mise en production. Vous pouvez mettre à jour le nom de mise en production avec des variables personnalisées en utilisant les commandes de journalisation de mise en production

Q : Comment spécifier la période de conservation de mes mises en production ?

R : Consultez Stratégies de conservation pour savoir comment configurer des stratégies de conservation pour vos pipelines de mise en production.

Articles connexes

• Déployer des artefacts de demande de tirage (pull request)
• Déployer à partir de plusieurs branches
• Configurer un pipeline de mise en production à plusieurs phases