# OPS 6. Comment réduire les risques liés au déploiement ?
Adoptez des approches qui fournissent un retour d’information rapide sur la qualité et permettent une reprise rapide à la suite de changements qui n’offrent pas les résultats escomptés. L’utilisation de ces pratiques diminue l’impact des problèmes découlant du déploiement des modifications.
**Topics**
+ [OPS06-BP01 Planifier les modifications infructueuses](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Déploiements de tests](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 Adoption de stratégies de déploiement sûres](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 Automatiser les tests et les annulations](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 Planifier les modifications infructueuses
Prévoyez de revenir à un état correct connu ou de remédier à la situation dans l’environnement de production si le déploiement entraîne un résultat indésirable. L’existence d’une politique visant à établir un tel plan aide toutes les équipes à développer des stratégies de récupération en cas d’échec des modifications. Parmi les exemples de stratégies, citons les étapes de déploiement et de restauration, les stratégies de changement, les indicateurs de fonctionnalité, l’isolation du trafic et le déplacement du trafic. Une seule version peut inclure plusieurs modifications de composants connexes. La stratégie doit permettre de résister ou de se remettre d’une défaillance de tout changement de composant.
**Résultat escompté :** vous avez préparé un plan de reprise détaillé pour votre modification en cas d’échec. En outre, vous avez réduit la taille de votre version afin de minimiser l’impact potentiel sur d’autres composants de la charge de travail. Vous avez ainsi réduit l’impact sur l’entreprise en diminuant le temps d’arrêt potentiel causé par une modification ratée et en augmentant la flexibilité et l’efficacité des temps de récupération.
**Anti-modèles courants :**
+ Vous avez effectué un déploiement et votre application est devenue instable, mais il semble qu’il y ait des utilisateurs actifs sur le système. Vous devez décider entre annuler la modification et avoir un impact sur les utilisateurs actifs et attendre pour annuler la modification en sachant que les utilisateurs peuvent être impactés de toute façon.
+ Après avoir modifié la routine, vos nouveaux environnements sont accessibles, mais l’un de vos sous-réseaux est devenu inaccessible. Vous devez décider de tout annuler ou d’essayer de réparer le sous-réseau inaccessible. Pendant cette période de détermination, le sous-réseau reste inaccessible.
+ Vos systèmes ne sont pas conçus de manière à pouvoir être mis à jour avec de plus petites versions. Par conséquent, il est difficile d’annuler ces modifications en bloc en cas d’échec du déploiement.
+ Vous n’utilisez pas l’infrastructure en tant que code (IaC) et vous avez effectué des mises à jour manuelles de votre infrastructure, ce qui a entraîné une configuration indésirable. Vous n’êtes pas en mesure de suivre et d’annuler efficacement les modifications manuelles.
+ Parce que vous n’avez pas mesuré l’augmentation de la fréquence de vos déploiements, votre équipe n’est pas incitée à réduire la taille de ses changements et à améliorer ses plans de restauration pour chaque modification, ce qui entraîne une augmentation des risques et des taux d’échec.
+ Vous ne mesurez pas la durée totale d’une panne causée par des modifications infructueuses. Votre équipe n’est pas en mesure d’établir des priorités et d’améliorer l’efficacité de son processus de déploiement et de son plan de reprise.
**Avantages de la mise en place de cette meilleure pratique :** le fait de disposer d'un plan de reprise après des modifications infructueuses permet de minimiser le temps moyen de restauration (MTTR) et de réduire l'impact sur votre entreprise.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Une stratégie et une pratique cohérentes et documentées, adoptées par les équipes de publication des versions, permettent à une organisation de planifier ce qui doit se passer en cas d’échec des modifications. La politique devrait permettre la correction à l’avance dans des circonstances spécifiques. Dans les deux cas, un plan de correction à l’avance ou de restauration doit être bien documenté et testé avant d’être déployé dans la production réelle, afin de réduire au minimum la durée nécessaire pour restaurer une modification.
### Étapes d’implémentation
1. Documentez les stratégies qui exigent des équipes qu’elles disposent de plans efficaces pour restaurer les modifications dans un délai donné.
1. Les stratégies doivent préciser les cas où une situation de correction à l’avance est autorisée.
1. Exigez qu’un plan de restauration documenté soit accessible à toutes les personnes concernées.
1. Précisez les conditions de restauration (par exemple, lorsqu’il s’avère que des modifications non autorisées ont été déployées).
1. Analysez le niveau d’impact de toutes les modifications liées à chaque composante d’une charge de travail.
1. Autorisez les modifications répétitives à être normalisées, modélisées et préautorisées si elles suivent un flux de travail cohérent qui applique les politiques de modification.
1. Réduisez l’impact potentiel de toute modification en en réduisant la taille, de sorte que la reprise prenne moins de temps et ait moins d’impact sur l’entreprise.
1. Veillez à ce que les procédures de restauration ramènent le code à l’état correct connu afin d’éviter les incidents dans la mesure du possible.
1. Intégrez des outils et des flux de travail pour appliquer vos politiques de manière programmée.
1. Faites en sorte que les données relatives aux modifications soient visibles pour les autres propriétaires de charges de travail afin d’améliorer la rapidité du diagnostic en cas de modification défaillante impossible à annuler.
1. Mesurez le degré de réussite de cette pratique à l’aide de données sur les modifications visibles et identifiez les améliorations itératives.
1. Utilisez des outils de surveillance pour vérifier le succès ou l’échec d’un déploiement afin d’accélérer la prise de décision concernant la restauration.
1. Mesurez la durée de l’interruption lors d’un changement infructueux afin d’améliorer continuellement vos plans de reprise.
**Niveau d’effort du plan d’implémentation :** moyen
## Ressources
**Bonnes pratiques associées :**
+ [OPS06-BP04 Automatiser les tests et les annulations](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**Documents connexes :**
+ [AWS Builders Library \$1 Garantir la sécurité des annulations lors des déploiements](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS Livre blanc \$1 Gestion du changement dans le cloud](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**Vidéos connexes :**
+ [re:Invent 2019 \$1 Amazon’s Approach to high-availability deployment](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)
# OPS06-BP02 Déploiements de tests
Testez les procédures de mise à disposition en préproduction en utilisant la même configuration de déploiement, les mêmes contrôles de sécurité, les mêmes étapes et les mêmes procédures qu’en production. Confirmez que toutes les étapes du déploiement se sont déroulées comme prévu, par exemple en inspectant les fichiers, les configurations et les services. Testez ensuite toutes les modifications à l’aide de tests fonctionnels, d’intégration et de charge, ainsi que de contrôles tels que les surveillances de l’état. En effectuant ces tests, vous pouvez identifier rapidement les problèmes de déploiement et avoir la possibilité de les planifier et de les atténuer avant la mise en production.
Vous pouvez créer des environnements parallèles temporaires pour tester chaque modification. Automatisez le déploiement des environnements de test à l’aide de l’infrastructure en tant que code (IaC) afin de réduire la quantité de travail nécessaire et d’assurer la stabilité, la cohérence et une livraison plus rapide des fonctionnalités.
**Résultat escompté :** votre organisation adopte une culture de développement piloté par les tests qui inclut des déploiements de tests. Cela permet de veiller à ce que les équipes se concentrent sur la création de valeur pour l’entreprise plutôt que sur la gestion des versions. Les équipes sont impliquées dès l’identification des risques de déploiement afin de déterminer les mesures d’atténuation appropriées.
**Anti-modèles courants :**
+ Pendant les mises en production, les déploiements non testés entraînent des problèmes fréquents qui nécessitent un dépannage et une remontée.
+ Votre version contient une infrastructure en tant que code (IaC) qui met à jour les ressources existantes. Vous n’êtes pas certain que l’IaC s’exécute correctement ou qu’elle a un impact sur les ressources.
+ Vous déployez une nouvelle fonctionnalité dans votre application. Elle ne fonctionne pas comme prévu et il n’y a aucune visibilité jusqu’à ce qu’elle soit signalée par les utilisateurs concernés.
+ Vous mettez à jour vos certificats. Vous installez accidentellement les certificats sur les mauvais composants, ce qui passe inaperçu et a un impact sur les visiteurs du site Web parce qu’il est impossible d’établir une connexion sécurisée avec le site Web.
**Avantages liés au respect de cette bonne pratique :** des tests approfondis en préproduction des procédures de déploiement et des modifications qu’elles introduisent minimisent l’impact potentiel sur la production causé par les étapes de déploiement. Cela permet d’accroître la confiance lors de la mise en production et de minimiser l’assistance opérationnelle sans ralentir la vitesse des changements apportés.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Il est tout aussi important de tester votre processus de déploiement que les modifications qui en découlent. Pour ce faire, vous pouvez tester vos étapes de déploiement dans un environnement de préproduction qui reflète le plus fidèlement possible l’environnement de production. Les problèmes courants, tels que les étapes de déploiement incomplètes ou incorrectes, ou les mauvaises configurations, peuvent être détectés avant la mise en production. De plus, vous pouvez tester vos étapes de reprise.
**Exemple client**
Dans le cadre de son pipeline d'intégration continue et de livraison continue (CI/CD), AnyCompany Retail exécute les étapes définies nécessaires pour publier des mises à jour d'infrastructure et de logiciels pour ses clients dans un environnement de type production. Le pipeline comprend des contrôles préalables pour détecter les altérations (détection des changements apportés aux ressources en dehors de votre IaC) dans les ressources avant le déploiement, ainsi que pour valider les actions que l’IaC entreprend lors de son lancement. Il valide les étapes du déploiement, en vérifiant par exemple que certains fichiers et configurations sont en place, que les services sont en cours d’exécution et qu’ils répondent correctement aux surveillances de l’état sur l’hôte local avant de s’enregistrer à nouveau auprès de l’équilibreur de charge. En outre, toutes les modifications font l’objet d’un certain nombre de tests automatisés, tels que des tests fonctionnels, de sécurité, de régression, d’intégration et de charge.
### Étapes d’implémentation
1. Effectuez des contrôles avant l’installation pour reproduire l’environnement de préproduction en production.
1. Utilisez [la détection de dérive](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) pour détecter lorsque les ressources ont été modifiées en dehors de CloudFormation.
1. Utilisez [des ensembles de modifications](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) pour vérifier que l'intention d'une mise à jour de la pile correspond aux actions entreprises lorsque l'ensemble de modifications est initié. CloudFormation
1. Cela déclenche une étape d’approbation manuelle dans [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) pour autoriser le déploiement dans l’environnement de préproduction.
1. Utilisez des configurations de déploiement telles que [AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html)des fichiers pour définir les étapes de déploiement et de validation.
1. Le cas échéant, [AWS CodeDeploy intégrez-le à d'autres AWS services](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) ou [AWS CodeDeploy intégrez-le aux produits et services partenaires](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. [Surveillez les déploiements](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) à l'aide CloudWatch d' AWS CloudTrail Amazon et des notifications d'SNSévénements Amazon.
1. Réalisez des tests automatisés après déploiement, y compris des tests fonctionnels, de sécurité, de régression, d’intégration et de charge.
1. [Résolution](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) des problèmes de déploiement
1. La validation réussie des étapes précédentes devrait lancer un mécanisme d’autorisation manuel pour autoriser le déploiement en production.
**Niveau d’effort du plan d’implémentation :** élevé
## Ressources
**Bonnes pratiques associées :**
+ [OPS05-BP02 Test et validation des modifications](ops_dev_integ_test_val_chg.md)
**Documents connexes :**
+ [AWS Bibliothèque pour les constructeurs \$1 Automatisation des déploiements sûrs et sans intervention directe \$1 Déploiements de test](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS Livre blanc \$1 Pratiquer l'intégration et la livraison continues sur AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [L’histoire d’Apollo, le moteur de déploiement d’Amazon](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+ [Comment tester et déboguer AWS CodeDeploy localement avant d'expédier votre code](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [Intégrer les tests de connectivité réseau au déploiement de l’infrastructure](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)
**Vidéos connexes :**
+ [ re:Invent 2020 \$1 Testing software and systems at Amazon ](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**Exemples connexes :**
+ [Tutoriel \$1 Déploiement et ECS service Amazon avec un test de validation](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 Adoption de stratégies de déploiement sûres
Les déploiements de production sécurisés contrôlent le flux des modifications bénéfiques dans le but de minimiser l’impact perçu de ces modifications sur les clients. Les contrôles de sécurité fournissent des mécanismes d’inspection permettant de valider les résultats souhaités et de limiter l’étendue de l’impact des défaillances introduites par les modifications ou des échecs de déploiement. Les déploiements sûrs peuvent inclure des stratégies telles que les indicateurs de fonctions, les déploiements sur un seul hôte, les déploiements continus (versions canary), les déploiements immuables, la division du trafic et les déploiements bleus/verts.
**Résultat escompté :** votre organisation utilise un système d’intégration continue et de livraison continue (CI/CD) qui permet d’automatiser des déploiements sûrs. Les équipes sont tenues d’utiliser des stratégies de déploiement sûres et appropriées.
**Anti-modèles courants :**
+ Vous déployez une modification infructueuse dans l’ensemble de l’environnement de production en une seule fois. Par conséquent, tous les clients sont touchés simultanément.
+ Une défaillance introduite lors d’un déploiement simultané dans tous les systèmes nécessite un lancement d’urgence. La correction pour tous les clients prend plusieurs jours.
+ La gestion des versions de production nécessite la planification et la participation de plusieurs équipes. Cela limite votre capacité à mettre fréquemment à jour les fonctionnalités pour vos clients.
+ Vous effectuez un déploiement mutable en modifiant vos systèmes existants. Après avoir découvert que la modification n’a pas abouti, vous devez modifier à nouveau les systèmes pour restaurer l’ancienne version, ce qui prolonge votre délai de récupération.
**Avantages liés au respect de cette bonne pratique :** les déploiements automatisés permettent de concilier la rapidité des déploiements et la cohérence des modifications apportées aux clients. Limiter l’impact permet d’éviter des échecs de déploiement coûteux et de maximiser la capacité des équipes à répondre efficacement aux défaillances.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Les défaillances de la livraison en continu peuvent entraîner une réduction de la disponibilité des services et de mauvaises expériences pour les clients. Pour maximiser le taux de réussite des déploiements, mettez en œuvre des contrôles de sécurité dans le processus de lancement de bout en bout afin de minimiser les erreurs de déploiement ; l’objectif étant de parvenir à zéro échec de déploiement.
**Exemple client**
AnyCompany Retail a pour mission de réaliser des déploiements avec un temps d’arrêt minimal ou nul, ce qui signifie qu’il n’y a pas d’impact perceptible pour ses utilisateurs pendant les déploiements. Pour ce faire, l’entreprise a établi des modèles de déploiement (voir le diagramme de flux de travail suivant), tels que les déploiements continus et les déploiements bleus/verts. Toutes les équipes adoptent un ou plusieurs de ces modèles dans leur pipeline CI/CD.
| Flux de travail CodeDeploy pour Amazon EC2 | Flux de travail CodeDeploy pour Amazon ECS | Flux de travail CodeDeploy pour Lambda |
| --- | --- | --- |
| ![\[Flux du processus de déploiement pour Amazon EC2\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/images/deployment-process-ec2.png) | ![\[Flux du processus de déploiement pour Amazon ECS\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/images/deployment-process-ecs.png) | ![\[Flux du processus de déploiement pour Lambda\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/images/deployment-process-lambda.png) |
### Étapes d’implémentation
1. Utilisez un flux de travail d’approbation pour lancer la séquence des étapes de déploiement de la production lors de la promotion en production.
1. Utilisez un système de déploiement automatisé tel que [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html). Les [options de déploiement de AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html) comprennent les déploiements sur place pour EC2/sur site et les déploiements bleus/verts pour EC2/sur site, AWS Lambda et Amazon ECS (voir le diagramme de flux de travail précédent).
1. Le cas échéant, [intégrez AWS CodeDeploy à d’autres services AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) ou [intégrez aux produits et services partenairesAWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. Utilisez des déploiements bleus/verts pour les bases de données telles qu’[Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) et [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html).
1. [Surveillez les déploiements](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) à l’aide d’Amazon CloudWatch, AWS CloudTrail et des notifications d’événements Amazon Simple Notification Service (Amazon SNS).
1. Effectuez des tests automatisés post-déploiement, y compris des tests fonctionnels, de sécurité, de régression, d’intégration et tout test de charge.
1. [Résolvez](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) les problèmes de déploiement.
**Niveau d’effort du plan d’implémentation :** moyen
## Ressources
**Bonnes pratiques associées:**
+ [OPS05-BP02 Test et validation des modifications](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP09 Procéder à des modifications fréquentes, mineures et réversibles](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 Automatisation complète de l’intégration et du déploiement](ops_dev_integ_auto_integ_deploy.md)
**Documents connexes :**
+ [AWS Builders’ Library \$1 Automatisation de déploiements sécurisés sans intervention \$1 Déploiements en production](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library \$1 Mon pipeline CI/CD est mon capitaine de versions \$1 Versions de production automatiques et sécurisées](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWSLivre blanc \$1 Mise en pratique de l’intégration continue et de la livraison continue sur AWS \$1 Méthodes de déploiement](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [AWS CodeDeploy Guide de l’utilisateur](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [Utilisation des configurations de déploiement dans AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [Configuration d’un déploiement de la version canary API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Types de déploiement Amazon ECS](https://docs.aws.amazon.com/)
+ [Déploiements bleus/verts entièrement gérés dans Amazon Aurora et Amazon RDS](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [Déploiements bleus/verts avec AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
**Vidéos connexes :**
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon’s Approach to high-availability deployment](https://www.youtube.com/watch?v=bCgD2bX1LI4)
**Exemples connexes :**
+ [Essai d’un exemple de déploiement bleu/vert dans AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [Atelier \$1 Création de pipelines CI/CD pour les déploiements canary Lambda à l’aide d’AWS CDK](https://catalog.workshops.aws/cdk-cicd-for-lambda-canary-deployment/en-US)
+ [Atelier \$1 Création de votre premier pipeline DevOps bleu/vert avec Amazon ECS](https://catalog.us-east-1.prod.workshops.aws/workshops/4b59b9fb-48b6-461c-9377-907b2e33c9df/en-US)
+ [Atelier \$1 Création de votre premier pipeline DevOps bleu/vert avec Amazon EKS](https://catalog.us-east-1.prod.workshops.aws/workshops/4eab6682-09b2-43e5-93d4-1f58fd6cff6e/en-US)
+ [Atelier \$1 EKS GitOps avec ArgoCD](https://catalog.workshops.aws/eksgitops-argocd-githubactions)
+ [Atelier \$1 Atelier CI/CD sur AWS](https://catalog.workshops.aws/cicdonaws/en-US)
+ [Implémentation de pipelines CI/CD entre comptes avec AWS SAM pour les fonctions Lambda basées sur des conteneurs](https://aws.amazon.com/blogs/compute/implementing-cross-account-cicd-with-aws-sam-for-container-based-lambda/)
# OPS06-BP04 Automatiser les tests et les annulations
Pour accroître la rapidité, la fiabilité et la confiance de votre processus de déploiement, mettez en place une stratégie de tests automatisés et de restauration dans les environnements de préproduction et de production. Automatisez les tests lors du déploiement en production afin de simuler les interactions entre l’homme et le système et de vérifier les modifications déployées. Automatisez la restauration pour revenir rapidement à un état antérieur sain connu. La restauration doit être déclenchée automatiquement dans des conditions prédéfinies, par exemple lorsque le résultat souhaité de la modification n’est pas atteint ou lorsque le test automatisé échoue. L’automatisation de ces deux activités améliore le taux de réussite de vos déploiements, minimise le temps de reprise et réduit l’impact potentiel sur l’entreprise.
**Résultat escompté :** vos tests automatisés et vos stratégies de restauration sont intégrés dans votre pipeline d’intégration continue et de livraison continue (CI/CD). Votre surveillance est en mesure de valider vos critères de réussite et de déclencher une restauration automatique en cas d’échec. Cela permet de minimiser l’impact sur les utilisateurs finaux et les clients. Par exemple, lorsque tous les résultats des tests ont été satisfaits, vous transférez votre code dans l’environnement de production où des tests de régression automatisés sont lancés, en utilisant les mêmes cas de test. Si les résultats des tests de régression ne correspondent pas aux attentes, une restauration automatisée est lancée dans le flux de travail du pipeline.
**Anti-modèles courants :**
+ Vos systèmes ne sont pas conçus de manière à pouvoir être mis à jour avec de plus petites versions. Par conséquent, il est difficile d’annuler ces modifications en bloc en cas d’échec du déploiement.
+ Votre processus de déploiement consiste en une série d’étapes manuelles. Après avoir apporté des modifications à votre charge de travail, vous commencez les tests de post-déploiement. Après les tests, vous vous rendez compte que votre charge de travail est inopérante et que les clients sont déconnectés. Vous commencez les opérations pour restaurer la version précédente. Toutes ces étapes manuelles retardent la reprise globale du système et ont un impact prolongé sur vos clients.
+ Vous avez passé du temps à développer des cas de tests automatisés pour des fonctionnalités qui ne sont pas fréquemment utilisées dans votre application, minimisant ainsi le retour sur investissement de votre capacité de tests automatisés.
+ Votre version est composée de mises à jour d’applications, d’infrastructures, de correctifs et de configurations qui sont indépendantes les unes des autres. Cependant, vous disposez d’un seul pipeline CI/CD qui fournit toutes les modifications en une seule fois. La défaillance d’un composant vous oblige à annuler toutes les modifications, ce qui rend votre restauration complexe et inefficace.
+ Votre équipe termine le travail de codage au cours du premier sprint et commence le travail du deuxième sprint, mais votre plan ne prévoyait pas de tests avant le troisième sprint. En conséquence, les tests automatisés ont révélé des défauts du premier sprint qui ont dû être résolus avant que les tests des produits livrables du deuxième sprint puissent commencer et la version entière est retardée, ce qui dévalorise vos tests automatisés.
+ Vos tests de régression automatisés pour la version de production sont terminés, mais vous ne surveillez pas l’état de la charge de travail. Comme vous ne savez pas si le service a redémarré ou non, vous ne savez pas si la restauration est nécessaire ou si elle a déjà eu lieu.
**Avantages liés au respect de cette bonne pratique :** l’automatisation des tests accroît la transparence de votre processus de test et votre capacité à couvrir davantage de fonctionnalités dans un laps de temps plus court. En testant et en validant les modifications en production, vous êtes en mesure d’identifier immédiatement les problèmes. L’amélioration de la cohérence avec les outils de test automatisés permet une meilleure détection des défauts. En restaurant automatiquement la version précédente, vous réduisez l’impact sur vos clients. La restauration automatisée inspire finalement plus de confiance dans vos capacités de déploiement en réduisant l’impact sur l’entreprise. Dans l'ensemble, ces capacités réduisent time-to-delivery tout en garantissant la qualité.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Automatisez le test des environnements déployés pour confirmer les résultats souhaités plus rapidement. Automatisez la restauration du dernier état connu de bonne qualité lorsque les résultats prédéfinis ne sont pas atteints, afin de minimiser les temps de récupération et de réduire les erreurs causées par les processus manuels. Intégrez des outils de test au flux de travail de votre pipeline afin de tester de manière cohérente et de minimiser les saisies manuelles. Privilégiez l’automatisation des cas de test, tels que ceux qui atténuent les risques les plus importants et qui doivent être testés fréquemment à chaque modification. En outre, vous pouvez automatiser la restauration en fonction de conditions spécifiques prédéfinies dans votre plan de test.
### Étapes d’implémentation
1. Établissez un cycle de test pour votre cycle de développement qui définit chaque étape du processus de test, de la planification des exigences au développement des cas de test, en passant par la configuration des outils, les tests automatisés et la clôture des cas de test.
1. Créez une approche de test spécifique à la charge de travail à partir de votre stratégie de test globale.
1. Envisagez, le cas échéant, une stratégie de tests continus tout au long du cycle de développement.
1. Choisissez des outils automatisés pour les tests et la restauration en fonction des besoins de votre entreprise et des investissements dans le pipeline.
1. Décidez des cas de test que vous souhaitez automatiser et de ceux qui doivent être exécutés manuellement. Ceux-ci peuvent être définis en fonction de la priorité de la valeur commerciale de la fonctionnalité testée. Alignez tous les membres de l’équipe sur ce plan et vérifiez leur responsabilité en ce qui concerne l’exécution des tests manuels.
1. Appliquez les capacités de test automatisé à des cas de test spécifiques qui se prêtent à l’automatisation, tels que les cas répétables ou fréquemment exécutés, ceux qui nécessitent des tâches répétitives ou ceux qui sont requis dans plusieurs configurations.
1. Définissez les scripts d’automatisation des tests ainsi que les critères de réussite dans l’outil d’automatisation afin que l’automatisation continue du flux de travail puisse être lancée lorsque des cas spécifiques échouent.
1. Définissez des critères d’échec spécifiques pour la restauration automatisée.
1. Donnez la priorité à l’automatisation des tests afin d’obtenir des résultats cohérents grâce à un développement approfondi des cas de test où la complexité et l’interaction humaine présentent un risque d’échec plus élevé.
1. Intégrez vos outils de tests automatisés et de restauration dans votre pipeline CI/CD.
1. Définissez des critères de réussite clairs pour vos modifications.
1. Surveillez et observez pour détecter ces critères et annuler automatiquement les modifications lorsque des critères de restauration spécifiques sont remplis.
1. Procédez à différents types de tests de production automatisés, tels que :
1. des tests A/B pour afficher les résultats par rapport à la version actuelle entre deux groupes d’utilisateurs ;
1. des tests Canary qui vous permettent de déployer votre modification auprès d’un sous-ensemble d’utilisateurs avant de la diffuser à tous ;
1. des tests d’indicateur de fonctions qui permettent d’activer et de désactiver une seule fonctionnalité de la nouvelle version depuis l’extérieur de l’application, de sorte que chaque nouvelle fonctionnalité puisse être validée une à la fois ;
1. des tests de régression pour vérifier les nouvelles fonctionnalités avec les composants interdépendants existants.
1. Contrôlez les aspects opérationnels de l’application, les transactions et les interactions avec d’autres applications et composants. Élaborez des rapports pour illustrer le degré de réussite des modifications en fonction de la charge de travail, afin de pouvoir identifier les parties de l’automatisation et du flux de travail qui peuvent être encore optimisées.
1. Élaborez des rapports sur les résultats des tests qui vous aideront à prendre des décisions rapides sur le fait d’invoquer ou non les procédures de restauration.
1. Mettez en œuvre une stratégie permettant une restauration automatisée sur la base de conditions d’échec prédéfinies résultant d’une ou de plusieurs de vos méthodes de test.
1. Développez vos cas de test automatisés pour permettre leur réutilisation dans le cadre de futures modifications répétées.
**Niveau d’effort du plan d’implémentation :** moyen
## Ressources
**Bonnes pratiques associées :**
+ [OPS06-BP01 Planifier les modifications infructueuses](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Déploiements de tests](ops_mit_deploy_risks_test_val_chg.md)
**Documents connexes :**
+ [AWS Builders Library \$1 Garantir la sécurité des annulations lors des déploiements](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [Redéployez et annulez un déploiement avec AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
+ [8 bonnes pratiques pour automatiser vos déploiements avec AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)
**Exemples connexes :**
+ [Test de l'interface utilisateur sans serveur à l'aide de Selenium, AWS LambdaAWS Fargate, et AWS des outils de développement](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)
**Vidéos connexes :**
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon’s Approach to high-availability deployment](https://www.youtube.com/watch?v=bCgD2bX1LI4)