Déployer n'est pas mettre en production
Un déploiement installe le nouveau code sur les serveurs ; une mise en production l'ouvre aux utilisateurs. Séparer les deux permet de livrer souvent tout en gardant le risque sous contrôle.
Canary release avec contrôles de santé automatiques
- 5%
- 25%
- 50%
- 100%
Part du trafic utilisateur par version
≤ 1%
≤ 300 ms
Nouvelle version déployée, sans trafic pour l'instant
Quatre stratégies, chacune pour une situation différente
Elles se combinent : une canary release derrière un feature flag est courante. Le choix dépend de votre architecture, de votre trafic et de l'organisation de vos utilisateurs.
Déploiement blue-green
Deux environnements de production identiques. La nouvelle version est déployée sur celui qui est inactif et vérifiée, puis tout le trafic bascule d'un coup. Revenir en arrière est tout aussi rapide.
- Idéal pour
- Les applications web et les API pour lesquelles un retour arrière rapide et complet compte avant tout.
- Comment nous la mettons généralement en œuvre
- Les emplacements de déploiement d'Azure App Service avec un échange d'emplacements, ou deux back-ends derrière Azure Front Door ou Application Gateway.
Canary release
La nouvelle version reçoit d'abord un petit pourcentage du trafic. Les indicateurs de santé décident si cette part augmente ou est retirée.
- Idéal pour
- Les services ayant assez de trafic et une bonne télémétrie pour juger sur un petit échantillon.
- Comment nous la mettons généralement en œuvre
- Répartition du trafic entre emplacements App Service ou révisions Azure Container Apps, ou origines pondérées dans Azure Front Door.
Anneaux de déploiement
Les utilisateurs sont répartis en anneaux, par exemple l'équipe projet, puis un département pilote, puis tout le monde. Chaque anneau permet de détecter les problèmes auprès d'un public restreint.
- Idéal pour
- Les applications métier internes, y compris les déploiements Dynamics 365, avec des groupes d'utilisateurs bien distincts.
- Comment nous la mettons généralement en œuvre
- Des environnements ou des groupes de sécurité distincts par anneau, promus par des étapes du pipeline avec une approbation entre chaque anneau.
Feature flags
Les nouvelles fonctionnalités sont déployées désactivées, puis activées par groupe d'utilisateurs quand le métier est prêt, sans nouveau déploiement.
- Idéal pour
- Dissocier la date de mise en service métier du déploiement technique.
- Comment nous la mettons généralement en œuvre
- La gestion des fonctionnalités d'Azure App Configuration ; dans Dynamics 365, des variables d'environnement ou des enregistrements de configuration vérifiés par le code.
Prévoir le chemin du retour
Une stratégie de mise en production ne vaut que par son retour arrière. Nous le définissons avant la mise en production, pas pendant l'incident.
- Décider à l'avance comment une mise en production sera annulée, et tester ce chemin dans un environnement inférieur.
- Garder les modifications de base de données rétrocompatibles (d'abord étendre, nettoyer plus tard) pour que la version précédente fonctionne encore après un retour arrière.
- Déclencher le retour arrière automatiquement sur des signaux de santé clairs plutôt que d'attendre une réunion.
- Pour les solutions Dynamics 365, revenir en arrière signifie généralement corriger en avançant avec une nouvelle version, ce qui rend les petites livraisons et une bonne couverture de tests encore plus importantes.
- Désigner un responsable clair pour chaque fenêtre de mise en production et publier de courtes notes de version, pour que le support sache ce qui a changé.