Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Utilisez le processus de livraison continue pour fournir rapidement et en toute sécurité une nouvelle valeur en production. Vous pouvez apporter de petites modifications fréquemment, ce qui réduit le risque de problèmes.
D’autres facteurs affectent les « difficultés de déploiement en production », notamment l’adoption de plusieurs environnements de distribution/déploiement. Une approche multienvironment vous permet de générer, de tester et de libérer du code avec une vitesse et une fréquence plus rapides pour rendre votre déploiement aussi simple que possible. Vous pouvez supprimer la surcharge manuelle et le risque d’une version manuelle, et automatiser le développement avec un processus multistage ciblant différents environnements.
Une architecture multienvironment commune comprend quatre niveaux :
- Développement
- Test
- Staging
- Production
Dans cette architecture, votre produit passe dans l’ordre du développement (l’environnement dans lequel vous développez les modifications apportées au logiciel) via production (l’environnement avec lequel vos utilisateurs interagissent directement). Vous pouvez également introduire un environnement UAT (User Acceptance Test) pour valider le flux métier de bout en bout.
| Environnement | Descriptif |
|---|---|
| Développement | Votre environnement de développement (développement) est l’endroit où les modifications apportées aux logiciels sont développées. |
| Test | Votre environnement de test permet aux testeurs humains ou aux tests automatisés d’essayer du code nouveau et mis à jour. Les développeurs doivent accepter de nouveaux codes et configurations par le biais de tests unitaires dans votre environnement de développement avant d’autoriser ces éléments à entrer dans un ou plusieurs environnements de test. |
| Staging | La préproduction est la phase où l'on effectue des tests finaux immédiatement avant le déploiement en production. Chaque environnement intermédiaire doit mettre en miroir un environnement de production réel aussi précisément que possible. |
| Test d'acceptation utilisateur (UAT) | Le test d’acceptation des utilisateurs (UAT) permet à vos utilisateurs finaux ou clients d’effectuer des tests pour vérifier/accepter le système logiciel avant qu’une application logicielle puisse passer à votre environnement de production. |
| Production | Votre environnement de production (production), parfois appelé live, est l’environnement avec lequel vos utilisateurs interagissent directement. |
Considérations relatives à la conception
Appliquez les considérations suivantes au développement des zones d’atterrissage Azure et des charges de travail Azure :
- Les environnements de test sont importants, car ils permettent aux développeurs de plateforme de tester les modifications avant le déploiement en production, ce qui réduit les risques liés à la livraison en production.
- Le fait de garder vos environnements aussi similaires que possible facilite la recherche d’erreurs liées à l’environnement dans les premières phases de test, ce qui augmente la vitesse de développement et de test et la fiabilité.
- S’il existe des différences dans la configuration de vos environnements, la « dérive de configuration » se produit, ce qui peut entraîner une perte de données, des déploiements plus lents et des échecs.
- Vous pouvez accélérer les déploiements, améliorer la cohérence de l’environnement et réduire la « dérive de configuration » entre les environnements en adoptant l’infrastructure en tant que code (IaC).
- Envisagez d’adopter des méthodes telles que Canary ou Blue-Green Deployments qui rendent les nouvelles fonctionnalités disponibles uniquement pour un ensemble limité d’utilisateurs de test en production et réduisent le temps de mise en production.
- Utilisez des vérifications sur les résultats des tests pour contrôler la transition du code du développement vers la production. Vous pouvez automatiser ces contrôles afin que les tests défaillants empêchent le déploiement automatique des modifications dans l’environnement suivant.
- Demandez aux utilisateurs désignés de passer en revue les pull requests avant le déploiement du code en production. Envisagez d’utiliser des référentiels avec une stratégie de branche pour gérer le processus de révision.
- Évitez les silos en permettant à tous les développeurs d’accéder à tous les environnements.
Workloads
Pour savoir comment gérer des environnements pour les charges de travail, reportez-vous à la FAQ à l’échelle de l’entreprise.
Zones d’atterrissage Azure
L’adoption de plusieurs environnements pour un déploiement de zone d’atterrissage Azure est courante lorsqu’un client souhaite tester les effets et les résultats des nouvelles attributions azure Policy, des attributions de rôles RBAC Azure, des appartenances aux groupes Microsoft Entra, la création des ressources Azure, etc.
L’approche de test pour l’échelle de l’entreprise décrit deux approches d’adoption différentes :
- Réplication de la hiérarchie des groupes d’administration dans l’environnement Canary et Production
- Abonnements bac à sable (sandbox)
Quelle que soit l’approche que vous suivez, vous devez toujours :
- Adoptez au moins un environnement pour les tests.
- Utilisez des principaux de service séparés à des fins de test et de production pour protéger vos environnements.
- Implémenter des vérifications et approbations automatisées pour valider et approuver les modifications avant de déployer une modification dans un environnement particulier