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 :
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.
Mise en file d’attente du travail de déploiement :
Azure Pipelines planifie le travail de déploiement sur un agent disponible.
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.
Télécharger des artefacts :
L’agent récupère et télécharge tous les artefacts spécifiés dans la version.
Exécuter la tâche de déploiement :
L’agent exécute toutes les tâches du travail de déploiement.
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.
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.
Versions et déploiements
Une mise en production est une construction qui contient un ensemble versionné d’artefacts spécifiés dans un pipeline CI/CD. Il inclut une capture instantanée de toutes les informations requises pour effectuer toutes les tâches et actions dans le pipeline de mise en production, telles que les phases, les tâches, les stratégies telles que les déclencheurs et les approbateurs ainsi que les options de déploiement. Il peut y avoir plusieurs mises en production d’un pipeline de mise en production, et des informations sur chacune d’elles sont stockées et affichées dans Azure Pipelines pour la période de rétention spécifiée.
Un déploiement est l’action d’exécuter les tâches d’une étape, qui peut inclure l’exécution de tests automatisés, le déploiement d’artefacts de build et les autres actions spécifiées pour cette phase. Le lancement d’une mise en production démarre chaque déploiement en fonction des paramètres et des stratégies définis dans le pipeline de mise en production d’origine. Il peut y avoir plusieurs déploiements de chaque mise en production, même pour une seule phase. Lorsque le déploiement d’une mise en production échoue pour une phase, vous pouvez redéployer la même mise en production dans cette phase. Pour redéployer une mise en production, accédez simplement à la mise en production que vous souhaitez déployer et sélectionnez Déployer.
Le diagramme suivant montre la relation entre les mises en production, les pipelines de mise en production et les déploiements.
Questions fréquentes (FAQ)
Q : Pourquoi mon déploiement n’a-t-il pas été déclenché ?
R : La création d’un pipeline de mise en production ne démarre pas automatiquement un déploiement. Voici quelques raisons pour lesquelles cela peut se produire :
Déclencheurs de déploiement : les déclencheurs de déploiement définis peuvent entraîner la pause du déploiement. Cela peut se produire avec des déclencheurs planifiés ou lorsqu’il y a un délai jusqu’à ce que le déploiement vers une autre étape soit terminé.
Stratégies de mise en file d’attente : ces stratégies déterminent l’ordre d’exécution et lorsque les mises en file d’attente sont mises en file d’attente pour le déploiement.
Approbations de prédéploiement ou portes : des étapes spécifiques peuvent nécessiter des approbations ou des portes de prédéploiement, empêchant le déploiement jusqu’à ce que toutes les conditions définies soient remplies.
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.