Utiliser des anneaux de déploiement avec des versions d’extension

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

Avec les anneaux de déploiement, vous pouvez déployer et valider progressivement les modifications apportées à votre extension en production, tout en limitant l’impact sur vos utilisateurs.

Nous vous déconseillons de déployer sur tous les environnements de production en même temps, ce qui expose tous les utilisateurs aux modifications. Un déploiement progressif expose les utilisateurs aux modifications au fil du temps, en validant les modifications en production avec moins d’utilisateurs.

Le tableau suivant présente les différences entre les zones affectées lorsque vous utilisez des anneaux et qu’aucun anneau n’est utilisé.

Sans anneaux	Zone affectée	Avec des anneaux
Manuel et sujet aux erreurs	Build	Automatisé et cohérent
Manuel et sujet aux erreurs	Version release	Automatisé et cohérent
heures	Durée de génération (T To)	Secondes
Jours	Délai de publication (TTR)	Minutes
Appel de l’utilisateur	Détection des problèmes	Proactif
Jours à semaines	Résolution du problème	Minutes à jours

Pour plus d’informations, consultez Configuration de vos pipelines de mise en production pour des déploiements sécurisés.

Prérequis

• Passez en revue les pipelines CI/CD et les Approbations pour obtenir une documentation détaillée des pipelines et les fonctionnalités d’approbation des versions.

Affecter des types d’utilisateurs

Déterminez les utilisateurs qui conviennent le mieux à chaque type d’utilisateur. Communiquez l’opportunité de fournir des commentaires et les niveaux de risque à chaque niveau, car il est essentiel de définir les attentes et de garantir la réussite. Dans l’exemple suivant, les utilisateurs sont divisés en trois groupes en production :

• Canaries : test volontaire des fonctionnalités dès qu’elles sont disponibles.
• Utilisateurs précoces : préversion volontaire des versions préliminaires, considérées comme plus affinées que les bits canary.
• Utilisateurs : consommez les produits, une fois qu’ils sont passés par les canaries et les premiers utilisateurs.

Mapper la topologie

Mappez la topologie de votre extension au modèle de déploiement en anneau pour limiter l’impact des modifications sur vos utilisateurs et fournir de la valeur. Pour nos extensions de communauté open source, nous utilisons principalement le déploiement en anneau pour exposer progressivement une nouvelle version à canary, aux utilisateurs précoces et aux utilisateurs.

Au niveau de l’application, la composition des extensions Azure DevOps est facile à digester, mettre à l’échelle et déployer indépendamment.

Chaque extension effectue les tâches suivantes :

• Dispose d’un de plusieurs fichiers web et de script
• Interfaces avec le client Principal
• Interfaces avec le client REST et les API REST
• Conserve l’état dans le cache ou le stockage résilient

Au niveau de l’infrastructure, les extensions sont publiées sur la Place de marché. Une fois que vous avez installé l’extension dans votre organisation, elle est hébergée par le portail de service Azure DevOps, avec l’état conservé dans le stockage Azure ou le stockage de données d’extension.

La topologie d’extension est parfaitement adaptée au modèle de déploiement en anneau et à publier l’extension sur chaque anneau de déploiement :

• Une version de développement privée pour l’anneau canary
• Une préversion privée pour l’anneau d’adoption précoce
• Version de production publique pour l’anneau des utilisateurs

Conseil

Publiez votre extension en tant que privé pour contrôler l’exposition aux utilisateurs invités.

Déplacer les modifications par le biais des anneaux de déploiement

Consultez l’exemple suivant de flux de déplacement des modifications par le biais d’anneaux de déploiement.

Utilisez l’extension Azure DevOps Developer Tools Build Tasks pour empaqueter et publier des extensions sur la Place de marché.

1. Un développeur du projet d’extension Countdown Widget valide une modification dans le dépôt GitHub .
2. La validation déclenche une build d’intégration continue.
3. La nouvelle build déclenche un déclencheur de déploiement continu, qui démarre automatiquement le déploiement de l’environnement Canaries .
4. Le déploiement de Canaries publie une extension privée sur la Place de marché et les partage avec des organisations prédéfinies. Seuls les Canaries sont affectés par le changement.
5. Le déploiement de Canaries déclenche le déploiement de l’environnement d’adoption anticipée. Une porte d’approbation de prédéploiement nécessite l’un des utilisateurs autorisés à approuver la version.
6. Le déploiement d’utilisateurs précoces publie une extension privée sur la Place de marché et les partage avec des organisations prédéfinies. Les Canaries et les premiers utilisateurs sont touchés par le changement.
7. Le déploiement d’utilisateurs précoces déclenche le déploiement de l’environnement Utilisateurs . Une porte d’approbation de prédéploiement plus stricte exige que tous les utilisateurs autorisés approuvent la version.
8. Le déploiement Des utilisateurs publie une extension publique sur la Place de marché. À ce stade, toutes les personnes qui ont installé l’extension dans leur organisation sont affectées par la modification.
9. Il est essentiel de se rendre compte que l’effet augmente à mesure que votre changement passe à travers les anneaux. L’exposition de la modification aux Canaries et aux premiers utilisateurs vous donne deux occasions de valider les bogues critiques de modification et de correctif logiciel avant de passer en production.

Surveiller les problèmes

La surveillance et les alertes peuvent vous aider à détecter et à atténuer les problèmes. Déterminez le type de données important, par exemple : problèmes d’infrastructure, violations et utilisation des fonctionnalités. Concentrez-vous sur les alertes actionnables pour éviter que les utilisateurs ne les ignorent et ne manquent pas de problèmes de priorité élevée.

Conseil

Commencez par des vues générales de vos données, des tableaux de bord visuels que vous pouvez regarder de loin et descendre en détail, selon les besoins. Effectuez un nettoyage régulier de vos vues et supprimez tout le bruit. Un tableau de bord visuel raconte une meilleure histoire que de nombreux e-mails de notification, souvent filtrés et oubliés par les règles de messagerie.

Utilisez Team Project Health et d’autres extensions pour créer une vue d’ensemble de vos pipelines, prospects et durées de cycle, et collecter d’autres informations. Dans l’exemple de tableau de bord, il est évident qu’il existe 34 builds réussies, 21 versions réussies, 1 version ayant échoué et 2 versions en cours.

Existe-t-il une dépendance vis-à-vis des indicateurs de fonctionnalité ?

Non. Parfois, vous devrez peut-être déployer certaines fonctionnalités dans le cadre d’une version, mais pas initialement exposée aux utilisateurs. Les indicateurs de fonctionnalité vous donnent un contrôle précis des fonctionnalités incluses dans votre modification. Par exemple, si vous n’êtes pas entièrement confiant sur une fonctionnalité, vous pouvez utiliser des indicateurs de fonctionnalité pour masquer la fonctionnalité dans un ou tous les anneaux de déploiement. Vous pouvez activer toutes les fonctionnalités de l’anneau des canaries et affiner un sous-ensemble pour les utilisateurs précoces et les utilisateurs de production, comme illustré dans l’image suivante.

Pour plus d’informations, consultez Expérimentation progressive avec des indicateurs de fonctionnalité.

FAQ

Q : Comment savez-vous qu’une modification peut être déployée sur l’anneau suivant ?

R : Vous devez disposer d’une liste de case activée cohérente pour les utilisateurs qui approuvent une version.

Q : Combien de temps attendez-vous avant d’envoyer une modification à l’anneau suivant ?

Il n’y a pas de durée fixe ou de période de « refroidissement ». Cela dépend du temps nécessaire pour effectuer toutes les validations de mise en production avec succès.

Q : Comment gérer un correctif logiciel ?

R : Le modèle de déploiement en anneau vous permet de traiter un correctif logiciel comme n’importe quelle autre modification. Plus vous interceptez un problème, plus vous pouvez déployer un correctif logiciel sans effet sur les anneaux en aval.

Q : Comment gérez-vous des variables qui s’étendent sur des environnements de mise en production partagé ?

R : Reportez-vous aux variables de mise en production par défaut et personnalisées.

Q : Comment gérer les secrets utilisés par le pipeline ?

R : Pour protéger les clés de chiffrement et d’autres secrets utilisés par vos pipelines, consultez Azure Key Vault.

Articles connexes

• Pratiques de déploiement sécurisé
• Expérimentation progressive avec des indicateurs de fonctionnalité
• Configurez vos pipelines de mise en production pour des déploiements sécurisés.