Concepts des portes de déploiement
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Les portes de déploiement dans Azure Pipelines sont ajoutées aux pipelines de libération pour s'assurer que les déploiements répondent à des critères spécifiques avant de poursuivre. Les points de contrôle sont essentiels pour garantir la fiabilité et la sécurité des déploiements en imposant des vérifications rigoureuses, ce qui permet d'obtenir des versions logicielles plus stables et plus sûres.
Les portes sont définies dans les conditions de pré-déploiement et de post-déploiement d'une étape de mise à disposition. Ils fournissent un mécanisme permettant de collecter automatiquement des signaux d’intégrité à partir de services externes, tels que la fonction Azure ou les API REST, pour contrôler la promotion des versions en fonction de ces signaux. Les portes fonctionnent avec les approbations pour s'assurer que les bonnes parties prenantes approuvent la mise en production et que la mise en production répond aux critères de qualité et de conformité nécessaires.
Cas d’usage
Voici quelques cas d’usage courants pour les portes de déploiement :
- Gestion des incidents: vérifiez que certains critères sont remplis avant de poursuivre le déploiement. Par exemple, assurez-vous que le déploiement se produit uniquement si aucun bogue de priorité zéro n’existe.
- Rechercher des approbations: intégrez Microsoft Teams ou Slack pour informer les utilisateurs externes tels que les auditeurs ou les responsables informatiques d’un déploiement et attendre leurs approbations.
- validation de qualité: interroger des métriques de pipeline telles que le taux de transmission ou la couverture du code et les déployer uniquement s’ils se trouvent dans un seuil prédéfini.
- Analyse de sécurité : effectuez des vérifications de sécurité telles que l’analyse des artefacts, la signature de code et la vérification de la stratégie. Une porte de déploiement peut lancer l’analyse et attendre qu’elle se termine, ou simplement vérifier l’achèvement.
- Expérience utilisateur par rapport à l'de référence : utilisez la collecte de données de produit pour vérifier les régressions de l'expérience utilisateur par rapport à l'état initial de référence. Les métriques de l’expérience utilisateur avant que le déploiement puisse être utilisé comme base de référence.
- gestion des modifications: attendez que les procédures de gestion des modifications dans un système tel que ServiceNow se terminent avant de poursuivre le déploiement.
- Santé de l'infrastructure: Exécutez la surveillance et validez l'infrastructure par rapport aux règles de conformité après le déploiement, ou attendez une utilisation optimale des ressources, et un rapport de sécurité positif.
La plupart des paramètres de santé varient au fil du temps, changeant régulièrement leur état de sain à malsain, puis de retour à sain. Pour tenir compte de ces variations, toutes les portes sont réévaluées périodiquement jusqu’à ce qu’elles réussissent toutes en même temps. L’exécution et le déploiement de la mise en production ne sont pas exécutés si toutes les portes ne réussissent pas dans le même intervalle et avant le délai d’expiration configuré.
Définir une porte pour une étape
Vous pouvez activer des portes au début d’une phase (conditions de prédéploiement) ou à la fin d’une phase (conditions de post-déploiement) ou pour les deux. Pour plus d’informations, consultez Installer des portes.
Le retard avant l’évaluation est un délai au début du processus d’évaluation de la porte qui permet aux portes d’initialiser, de stabiliser et de commencer à fournir des résultats précis pour le déploiement actuel. Pour plus d'informations, voir Flux d'évaluation des portes.
- Pour les portes de prédéploiement, le retard est le temps nécessaire à la journalisation de tous les bogues par rapport aux artefacts en cours de déploiement.
- Pour les portes post-déploiement , le délai serait le temps maximal nécessaire pour que l'application déployée atteigne un état opérationnel stable, le temps pris pour exécuter tous les tests requis à l'étape de déploiement, et le temps requis pour que les incidents soient enregistrés après le déploiement.
Les portes suivantes sont disponibles par défaut :
- Invoquer la fonction Azure: déclencher l’exécution d’une fonction Azure et assurer un achèvement réussi. Pour plus d'informations, voir Tâche de fonction Azure.
- Interroger les alertes Azure Monitor : observez les règles d’alerte Azure Monitor configurées pour les alertes actives. Pour plus d’informations, consultez Tâche Azure Monitor.
- Appeler l’API REST: appelez une API REST et continuez si elle retourne une réponse réussie. Pour plus d’informations, consultez la tâche Appeler l’API REST.
- Éléments de travail issus d'une requête: Vérifiez que le nombre d'éléments de travail correspondants retournés à partir d'une requête est compris dans une limite. Pour plus d'informations, voir la tâche Demander des éléments de travail.
- Vérifier la conformité d’Azure Policy: évaluez la conformité Azure Policy sur les ressources dans l’étendue d’un abonnement et d’un groupe de ressources donnés, et éventuellement à un niveau de ressource spécifique. Pour plus d'informations, voir Tâche de vérification de la conformité de la stratégie Azure.
Vous pouvez également créer vos propres portes avec des extensions de la Place de marché.
Les options d’évaluation qui s’appliquent à toutes les portes sont les suivantes :
- Délai entre la réévaluation des portes. Intervalle de temps entre les évaluations successives des portes. À chaque intervalle d’échantillonnage, de nouvelles demandes sont envoyées simultanément à chaque porte et les nouveaux résultats sont évalués. La recommandation est que l’intervalle d’échantillonnage est supérieur au temps de réponse classique le plus long des portes configurées pour permettre la réception de toutes les réponses pour l’évaluation.
- Délai d’expiration avant l’échec des portes. Période d’évaluation maximale pour toutes les portes. Le déploiement est rejeté si le délai d’expiration est atteint avant que toutes les portes réussissent pendant le même intervalle d’échantillonnage.
- Portes et approbations. Sélectionnez l’ordre d’exécution requis pour les portes et les approbations si vous avez configuré les deux. Pour les conditions de prédéploiement, la valeur par défaut consiste à demander d’abord des approbations manuelles (utilisateur), puis à évaluer les portes ensuite, évitant ainsi d’évaluer les fonctions de porte si l’utilisateur rejette la mise en production. Pour les conditions de post-déploiement, la valeur par défaut est l'évaluation des points de contrôle et la requête d'approbation manuelle uniquement lorsque tous les points de contrôle ont été franchis avec succès, ce qui garantit que les approbateurs disposent de toutes les informations nécessaires pour approuver la validation.
Pour plus d’informations sur l’analytique des portes, consultez Afficher les journaux d’approbations et Surveiller et suivre les déploiements.
Exemples de flux d’évaluation de porte
Le diagramme suivant illustre le flux d’évaluation de la porte où, après la période de stabilisation initiale et trois intervalles d’échantillonnage, le déploiement est approuvé.
Le diagramme suivant illustre le flux d’évaluation de la porte où, après la période de retard de stabilisation initiale, toutes les portes n’ont pas réussi à chaque intervalle d’échantillonnage. Dans ce cas, une fois la période d’expiration terminée, le déploiement est rejeté.
