Modéliser un workflow complexe avec des étapes parallèles et des dépendances entre les étapes.
→Utilisez les pipelines YAML multi-étapes. Utilisez le mot-clé `dependsOn` pour les dépendances d'étape et configurez des jobs parallèles au sein des étapes.
Pourquoi: YAML offre l'approche la plus flexible et basée sur le code pour l'orchestration complexe, supérieure aux pipelines classiques ou à l'enchaînement de pipelines séparés.
Implémenter un déploiement sans interruption et à faible risque pour une application web avec une capacité de rollback instantané.
→Utilisez les slots de déploiement Azure App Service. Déployez sur un slot de staging (vert), validez, puis effectuez un échange de slot avec la production (bleu).
Pourquoi: Un échange de slot est une opération atomique, quasi-instantanée qui redirige le trafic. Le rollback est aussi simple que de rééchanger.
Référence↗
Minimiser la duplication de pipeline pour de nombreux microservices qui partagent des étapes de build/déploiement communes mais nécessitent des personnalisations spécifiques.
→Créez des templates YAML dans un dépôt central. Dans chaque pipeline spécifique au service, utilisez le mot-clé `extends` et passez des paramètres pour la personnalisation.
Pourquoi: `extends` promeut les principes DRY et applique les standards tout en permettant la flexibilité via des paramètres. Plus puissant que les groupes de tâches pour des structures de pipeline entières.
Restreindre une étape de pipeline (par exemple, déploiement en production) à s'exécuter uniquement lors des fusions vers une branche spécifique (par exemple, main).
→Utilisez une `condition` sur l'étape ou le job. Par exemple, `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`.
Pourquoi: Les builds de validation de PR utilisent une référence de branche source différente (par exemple, `refs/pull/...`), donc cette condition empêche correctement le déploiement pendant le cycle de vie de la PR.
Déployer des applications d'Azure DevOps vers des serveurs on-premises derrière un pare-feu d'entreprise.
→Installez des agents auto-hébergés sur les serveurs on-premises. Enregistrez-les dans un pool d'agents dans Azure DevOps.
Pourquoi: Les agents auto-hébergés initient une communication sortante vers Azure DevOps, donc aucune règle de pare-feu entrante n'est nécessaire. Ils peuvent accéder aux ressources du réseau local pour le déploiement.
Exiger une approbation multi-personnes pour les déploiements en production et les restreindre à des fenêtres de maintenance spécifiques.
→Définissez un environnement Azure DevOps pour la production. Configurez les approbations avec les approbateurs requis. Ajoutez un contrôle "Business Hours" comme porte pour faire respecter la plage horaire.
Pourquoi: Les environnements centralisent les contrôles de déploiement. Les approbations et les portes offrent une application robuste et automatisée des politiques avant l'exécution d'une étape.
Contrôler l'exposition des fonctionnalités aux utilisateurs sans redéployer l'application, avec des mises à jour quasi-en temps réel.
→Utilisez Azure App Configuration pour la gestion des fonctionnalités. Instrumentez l'application pour lire les drapeaux et activez ses capacités de rafraîchissement dynamique.
Pourquoi: Découple les releases de fonctionnalités des déploiements. App Configuration fournit une UI centralisée et des SDK pour les mises à jour dynamiques, évitant les redémarrages d'application.
Gérer l'état d'un cluster Kubernetes de manière déclarative, où Git est la seule source de vérité et les changements sont automatiquement appliqués.
→Déployez un agent GitOps comme Flux ou ArgoCD sur le cluster AKS. Configurez l'agent pour qu'il surveille un dépôt Git contenant les manifestes Kubernetes et synchronise automatiquement l'état du cluster.
Pourquoi: Ce modèle basé sur le "pull" permet une réconciliation continue et une détection de dérive, ce qui est au cœur de GitOps. Il est plus robuste que les pipelines `kubectl` basés sur le "push".
Gérer l'état Terraform pour la collaboration d'équipe, en assurant la sécurité et en empêchant les modifications concurrentes.
→Configurez le backend Terraform pour utiliser un compte de stockage Azure. Cela fournit un stockage d'état distant, avec un verrouillage d'état géré via le bail de blob Azure.
Pourquoi: Empêche la corruption du fichier d'état due à des opérations `apply` simultanées et maintient les données d'état sensibles hors du contrôle de code source.
Référence↗
Dans un monorepo, déclencher le pipeline CI d'une application uniquement lorsque des fichiers dans son répertoire spécifique (ou un répertoire partagé) sont modifiés.
→Dans le YAML du pipeline, utilisez le filtre `trigger.paths.include` pour spécifier les répertoires pertinents, par exemple, `include: ['/apps/frontend/**', '/apps/shared/**']`.
Pourquoi: Cela évite les builds inutiles pour des changements de code non liés, économisant du temps CI et des ressources de calcul.
Optimiser une étape de test avec des tests rapides (unitaires) et lents (d'intégration) pour un feedback plus rapide.
→Exécutez les tests unitaires et les tests d'intégration dans des jobs parallèles au sein de la même étape.
Pourquoi: L'exécution parallèle fournit les résultats des tests unitaires beaucoup plus rapidement tandis que les tests plus lents s'exécutent simultanément. La durée totale de l'étape est déterminée par le job le plus long, et non par la somme.
Versionner automatiquement un package de bibliothèque basé sur l'historique des commits pour communiquer clairement l'impact des changements (cassant, fonctionnalité, correction).
→Intégrez un outil comme GitVersion dans le pipeline CI. Il analyse les messages de commit, les branches et les tags pour calculer automatiquement une version SemVer (Majeur.Mineur.Patch).
Pourquoi: SemVer fournit un versionnement significatif sur lequel les consommateurs peuvent compter pour la gestion des dépendances, contrairement aux numéros de build ou aux hachages de commit.
Déployer une application dans plusieurs régions géographiques une par une, avec validation après chaque déploiement régional.
→Utilisez un pipeline YAML multi-étapes avec des étapes séquentielles, une pour chaque région, en utilisant `dependsOn` pour appliquer l'ordre. Utilisez des portes d'environnement entre les étapes pour la validation.
Pourquoi: Ce modèle de déploiement basé sur des anneaux contient le rayon d'impact d'un mauvais déploiement à une seule région, permettant un rollback avant d'impacter tous les utilisateurs.
Configurer un pipeline pour supporter un modèle de développement basé sur le tronc, garantissant que la branche principale est toujours déployable.
→Configurez un déclencheur CI sur la branche `main`. Appliquez les PRs avec une politique de validation de build qui exécute des tests rapides et complets. Intégrez des notifications rapides (par exemple, vers Teams/Slack) pour les échecs de build.
Pourquoi: Un feedback immédiat est critique dans le développement basé sur le tronc. Cette combinaison empêche le code cassé de fusionner et assure une correction rapide lorsque des problèmes surviennent.
Transférer de gros artefacts (par exemple, des modèles ML, >5 Go) entre les étapes de pipeline de manière efficace.
→Téléchargez le grand artefact vers Azure Blob Storage dans l'étape productrice. Passez l'URI du blob à l'étape consommatrice comme variable de sortie.
Pourquoi: Azure Blob Storage est plus rentable et plus performant que les artefacts de pipeline intégrés pour les fichiers de plusieurs gigaoctets.
Réduire les temps de build en évitant de retélécharger les dépendances (par exemple, NuGet, npm) à chaque exécution.
→Utilisez la tâche `Cache@2`. Définissez une clé basée sur le fichier de verrouillage du package (par exemple, `packages.lock.json`). La tâche stockera et restaurera le dossier de dépendances.
Pourquoi: Peut économiser plusieurs minutes par build en restaurant depuis un cache local rapide au lieu de récupérer depuis des dépôts externes.
Construire ou déployer le même code sur plusieurs cibles (par exemple, différents OS, régions) en parallèle.
→Utilisez une `strategy: matrix` dans le job du pipeline YAML. Définissez des variables pour chaque combinaison, ce qui générera un job pour chaque entrée de la matrice.
Pourquoi: Une stratégie de matrice maintient la définition du pipeline DRY, créant plusieurs variations de job à partir d'une seule définition et les exécutant en parallèle.
Implémenter un déploiement Canary sur AKS qui déplace automatiquement le trafic et promeut ou annule en fonction de métriques en temps réel.
→Utilisez un contrôleur de livraison progressive comme Flagger, intégré à un service mesh (par exemple, Istio) et un fournisseur de métriques (par exemple, Prometheus).
Pourquoi: Flagger automatise l'ensemble du processus d'analyse Canary, offrant une livraison progressive plus sûre et plus fiable que les scripts manuels.
Un pipeline d'application doit se déclencher lorsque le code change dans son propre dépôt OU dans un dépôt de bibliothèque partagée séparé.
→Dans le YAML de l'application, définissez la bibliothèque partagée sous `resources.repositories` et configurez un bloc `trigger` sur cette ressource.
Pourquoi: Crée une dépendance déclarative entre les dépôts, garantissant que l'application est toujours reconstruite avec les derniers composants partagés.
Un pipeline doit créer une infrastructure temporaire pour les tests et s'assurer qu'elle est détruite après, même si les tests échouent.
→Utilisez un pipeline multi-étapes avec des étapes d'application et de destruction séparées pour l'IaC (Terraform/Bicep). Configurez l'étape de destruction avec `condition: always()` ainsi que l'étape de création.
Pourquoi: La condition `always()` garantit que l'étape de nettoyage s'exécute indépendamment du succès ou de l'échec des étapes précédentes, évitant les ressources orphelines.
Empêcher un déploiement en production de se poursuivre à moins qu'il n'y ait une demande de changement approuvée dans un outil ITSM comme ServiceNow.
→Configurez une porte d'environnement qui invoque la porte "Query ServiceNow" pour vérifier le statut de la demande de changement.
Pourquoi: Automatise l'intégration avec les processus de gestion du changement d'entreprise, garantissant la conformité sans transferts manuels.
Fournir un pool d'agents de build auto-hébergés qui s'adapte dynamiquement à la demande pour réduire les temps d'attente et contrôler les coûts.
→Configurez un pool d'agents Azure DevOps en utilisant un groupe de machines virtuelles identiques Azure (VMSS), configuré pour s'adapter automatiquement en fonction du nombre de jobs en attente.
Pourquoi: Les agents VMSS combinent la personnalisation des agents auto-hébergés avec l'élasticité des agents hébergés dans le cloud, optimisant les performances et les coûts.
Déployer les changements de schéma de base de données d'une manière qui prévient la perte de données et supporte les rollbacks.
→Utilisez un outil de migration (par exemple, Flyway, DbUp). Implémentez le pattern expand/contract pour les changements de schéma afin de maintenir la compatibilité descendante.
Pourquoi: Les outils de migration fournissent la gestion de version et le contrôle. Le pattern expand/contract découple les rollbacks d'application et de base de données, permettant des déploiements plus sûrs.
Les agents auto-hébergés manquent d'espace disque à cause des artefacts de build accumulés.
→Dans le YAML du pipeline, au niveau du job, configurez `workspace: clean: all`.
Pourquoi: Cette configuration préventive du pipeline résout la cause première sans nécessiter d'intervention manuelle ou de changements continus d'infrastructure.
Les tests d'intégration nécessitent une instance de base de données isolée pour chaque exécution de pipeline.
→Définissez une ressource de conteneur (par exemple, SQL Server, Postgres) comme service dans le YAML du pipeline. Le job de test peut alors se connecter à ce service éphémère.
Pourquoi: Fournit des dépendances rapides, isolées et automatiquement nettoyées pour les tests, évitant les interférences de test et simplifiant la configuration.
Améliorer la fiabilité et la performance de la restauration de packages depuis des dépôts publics (par exemple, npmjs, nuget.org).
→Dans Azure Artifacts, créez un flux et configurez des sources amont pointant vers les dépôts publics. Faites en sorte que les clients consomment des packages depuis le flux Azure Artifacts.
Pourquoi: Le flux met en cache les packages des sources amont, protégeant contre les pannes des dépôts publics et accélérant les restaurations pour les packages fréquemment utilisés.
Déployer un chart Helm dans plusieurs environnements (dev, prod) avec des valeurs de configuration différentes.
→Utilisez des fichiers `values-<env>.yaml` séparés pour chaque environnement. Dans la tâche `HelmDeploy`, utilisez l'entrée `valueFile` pour spécifier le fichier approprié et `overrideValues` pour injecter des valeurs dynamiques comme les tags d'image.
Pourquoi: Ce modèle sépare la configuration statique de l'environnement des variables de pipeline dynamiques, gardant les déploiements propres et maintenables.
