

# OPS 6. Comment réduire les risques liés au déploiement ?
<a name="ops-06"></a>

 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 Adopter des stratégies de déploiement sûres](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 Automatiser les tests et les restaurations](ops_mit_deploy_risks_auto_testing_and_rollback.md)

# OPS06-BP01 Planifier les modifications infructueuses
<a name="ops_mit_deploy_risks_plan_for_unsucessful_changes"></a>

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 des résultats indésirables. 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 politiques, citons les étapes de déploiement et de restauration, les politiques de changement, les indicateurs de fonction, 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 souhaité :** 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 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 liés au respect de cette bonne pratique :** Disposer d'un plan de reprise en cas de modifications infructueuses permet de minimiser le temps moyen de récupération (MTTR) et de réduire l'impact sur votre entreprise. 

 **Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Élevé 

## Directives d'implémentation
<a name="implementation-guidance"></a>

 Une politique 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
<a name="implementation-steps"></a>

1.  Documentez les politiques qui exigent des équipes qu'elles disposent de plans efficaces pour restaurer les modifications dans un délai donné. 

   1.  Les politiques 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
<a name="resources"></a>

 **Bonnes pratiques associées :** 
+  [OPS06-BP04 Automatiser les tests et les restaurations](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documents connexes :** 
+ [ Builders Library AWS \$1 Exécuter des annulations sûres pendant les déploiements ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [ Livre blanc AWS \$1 Gestion des modifications 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
<a name="ops_mit_deploy_risks_test_val_chg"></a>

 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 souhaité :** 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 sous forme de 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 de risque exposé si cette bonne pratique n'est pas respectée :** Élevé 

## Directives d'implémentation
<a name="implementation-guidance"></a>

 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 et de livraison continues (CI/CD), AnyCompany Retail exécute les étapes définies nécessaires au lancement de l'infrastructure et des mises à jour logicielles 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
<a name="implementation-steps"></a>

1.  Effectuez des contrôles avant l'installation pour reproduire l'environnement de pré-production en production. 

   1.  Utilisez [la détection des altérations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) pour détecter si des ressources ont été modifiées en dehors de CloudFormation. 

   1.  Utilisez [des jeux de modifications](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) pour vérifier que l'intention de la mise à jour de la pile correspond aux actions entreprises par CloudFormation lorsque le jeu de modifications est lancé. 

1.  Cela déclenche une étape d'approbation manuelle dans [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) afin d'autoriser le déploiement dans l'environnement de pré-production. 

1.  Utilisez les configurations de déploiement telles que les fichiers [AppSpec AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) pour définir les étapes de déploiement et de validation. 

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 AWS CodeDeploy aux produits et services des 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 de Amazon CloudWatch, de AWS CloudTrail et des notifications d'événements Amazon SNS. 

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ésolvez les](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) 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
<a name="resources"></a>

 **Bonnes pratiques associées :** 
+  [OPS05-BP02 Tester et valider les modifications](ops_dev_integ_test_val_chg.md) 

 **Documents connexes :** 
+ [ Builders' Library AWS \$1 Automatisation de déploiements sécurisés sans intervention \$1 Déploiements tests ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [ Livre blanc AWS \$1 Mise en pratique de l'intégration continue et de la livraison continue sur AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [ The Story of Apollo - Amazon's Deployment Engine ](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/) 
+ [ Integrating Network Connectivity Testing with Infrastructure Deployment ](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 maintenance Amazon ECS à l'aide d'un test de validation ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)

# OPS06-BP03 Adopter des stratégies de déploiement sûres
<a name="ops_mit_deploy_risks_deploy_mgmt_sys"></a>

 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 bleu/vert. 

 **Résultat souhaité :** 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
<a name="implementation-guidance"></a>

 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 bleu/vert. 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/2024-06-27/framework/images/deployment-process-ec2.png)  |  ![\[Flux du processus de déploiement pour Amazon ECS\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2024-06-27/framework/images/deployment-process-ecs.png)  |  ![\[Flux du processus de déploiement pour Lambda\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2024-06-27/framework/images/deployment-process-lambda.png)  | 

### Étapes d’implémentation
<a name="implementation-steps"></a>

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 AWS CodeDeploy [comprennent les](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html) déploiements sur place pour EC2/sur site et les déploiements bleu/vert 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 AWS CodeDeploy aux produits et services des partenaires](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html). 

1.  Utilisez les déploiements bleu/vert pour les bases de données telles que [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 des notifications d’événements Amazon CloudWatch, AWS CloudTrail et 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 les](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) problèmes de déploiement. 

 **Niveau d’effort du plan d’implémentation :** Moyen 

## Ressources
<a name="resources"></a>

 **Bonnes pratiques associées :** 
+  [OPS05-BP02 Tester et valider les modifications](ops_dev_integ_test_val_chg.md) 
+  [OPS05-BP09 Effectuer des modifications fréquentes, légères et réversibles](ops_dev_integ_freq_sm_rev_chg.md) 
+  [OPS05-BP10 Automatiser complètement l'intégration et le déploiement](ops_dev_integ_auto_integ_deploy.md) 

 **Documents connexes :** 
+ [Builders’ Library AWS \$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)
+ [Builders Library AWS \$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)
+ [Livre blanc AWS \$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)
+ [Guide de l’utilisateur AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [Working with deployment configurations in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [Set up an API Gateway canary release deployment ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Types de déploiement Amazon ECS](https://docs.aws.amazon.com/)
+ [Déploiements bleu/vert 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/)
+ [Blue/Green deployments with 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 :** 
+ [Essayer 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 Lambda Canary à l’aide de AWS CDK](https://catalog.us-east-1.prod.workshops.aws/workshops/5195ab7c-5ded-4ee2-a1c5-775300717f42/en-US)
+ [Atelier \$1 Déploiement bleu/vert et canary pour EKS et ECS](https://catalog.us-east-1.prod.workshops.aws/workshops/2175d94a-cd79-4ed2-8e7e-1f0dd1956a3a/en-US)
+ [Atelier \$1 Création d’un pipeline CI/CD](https://catalog.us-east-1.prod.workshops.aws/workshops/00bc829e-fd7c-4204-9da1-faea3cf8bd88/en-US)

# OPS06-BP04 Automatiser les tests et les restaurations
<a name="ops_mit_deploy_risks_auto_testing_and_rollback"></a>

 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 souhaité :** 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 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 permettent de réduire les délais de livraison tout en garantissant la qualité. 

 **Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyen 

## Directives d'implémentation
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>

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 chaque membre 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 que vous puissiez 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'appeler 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
<a name="resources"></a>

 **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 :** 
+ [ Builders Library AWS Builders Library \$1 Exécuter des annulations sûres pendant les déploiements ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+  [Redéployer et annuler 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 :** 
+ [ Tests d'interface utilisateur sans serveur à l'aide de Selenium, AWS Lambda, AWS Fargate et AWS Developer Tools ](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)