

# OPS 6. ¿Cómo mitiga los riesgos de implementación?


 Adopte métodos que proporcionen una respuesta inmediata sobre la calidad y logren una recuperación rápida de los cambios que no obtengan los resultados deseados. El uso de estas prácticas ayuda a mitigar el impacto de los problemas generados con la implementación de cambios. 

**Topics**
+ [

# OPS06-BP01 Planificación para hacer frente a los cambios infructuosos
](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [

# OPS06-BP02 Implementaciones de prueba
](ops_mit_deploy_risks_test_val_chg.md)
+ [

# OPS06-BP03 Uso de estrategias de implementación seguras
](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [

# OPS06-BP04 Automatización de las pruebas y la reversión
](ops_mit_deploy_risks_auto_testing_and_rollback.md)

# OPS06-BP01 Planificación para hacer frente a los cambios infructuosos
OPS06-BP01 Planificación para hacer frente a los cambios infructuosos

Planifique la reversión a un estado óptimo conocido o la corrección en el entorno de producción si una implementación causa un resultado no deseado. Tener una política para establecer un plan de este tipo ayuda a todos los equipos a desarrollar estrategias para recuperarse de los cambios fallidos. Algunos ejemplos de estrategias son los pasos de implementación y reversión, las políticas de cambio, los indicadores de características, el aislamiento del tráfico y el cambio de tráfico. Una sola versión puede incluir varios cambios de componentes relacionados. La estrategia debe proporcionar la capacidad de resistir o recuperarse de un error de cualquier cambio de componente.

 **Resultado deseado:** ha preparado un plan de recuperación detallado para su cambio en caso de que no tenga éxito. Además, ha reducido el tamaño de su versión para minimizar el impacto potencial en otros componentes de la carga de trabajo. Como resultado, ha reducido su impacto empresarial al acortar el posible tiempo de inactividad causado por un cambio infructuoso y ha aumentado la flexibilidad y la eficiencia de los tiempos de recuperación. 

 **Patrones comunes de uso no recomendados:** 
+  Ha llevado a cabo una implementación y la aplicación se comporta de forma inestable, aunque parece que hay usuarios activos en el sistema. Debe decidir si deshacer el cambio, lo que afectará a los usuarios activos, o esperar a revertir el cambio sabiendo que los usuarios pueden verse afectados igualmente. 
+  Después de hacer un cambio de rutina, sus nuevos entornos son accesibles, pero una de sus subredes ha quedado inaccesible. Tiene que decidir si revertirlo todo o intentar reparar la subred inaccesible. Mientras toma esa decisión, no se podrá acceder a la subred. 
+  Sus sistemas no tienen una arquitectura que permita actualizarlos con versiones más pequeñas. Como resultado, tiene dificultades para revertir esos cambios masivos durante una implementación infructuosa. 
+  No utiliza la infraestructura como código (IaC) y ha llevado a cabo actualizaciones manuales en su infraestructura que han dado lugar a una configuración no deseada. No puede hacer un seguimiento eficaz de los cambios manuales ni revertirlos. 
+  Como no ha medido el aumento de la frecuencia de sus implementaciones, su equipo no tiene incentivos para reducir el tamaño de los cambios y mejorar los planes de reversión para cada cambio, lo que genera más riesgos y mayores tasas de errores. 
+  No mide la duración total de una interrupción provocada por cambios infructuosos. Su equipo no puede establecer prioridades ni mejorar la eficacia del proceso de implementación y del plan de recuperación. 

 **Beneficios de establecer esta práctica recomendada:** tener un plan para recuperarse de cambios fallidos minimiza el tiempo medio de recuperación (MTTR) y reduce el impacto en la organización. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
Guía para la implementación

 La adopción por parte de los equipos de lanzamiento de políticas y prácticas coherentes permite a la organización planificar lo que debe suceder si se producen cambios infructuosos. La política debe permitir aplicar correcciones temporales en circunstancias concretas. En cualquier situación, un plan de corrección temporal o reversión debe estar bien documentado y probado antes de implementarlo en producción en vivo para minimizar el tiempo que lleva revertir un cambio. 

### Pasos para la implementación
Pasos para la implementación

1.  Documente las políticas que requieren que los equipos tengan planes efectivos para revertir los cambios dentro de un período específico. 

   1.  Las políticas deben especificar cuándo se permite una situación de corrección temporal. 

   1.  Exija un plan de reversión documentado al que puedan acceder todas las partes involucradas. 

   1.  Especifique los requisitos para la reversión (por ejemplo, cuando se descubra que se han implementado cambios no autorizados). 

1.  Analice el grado de impacto de todos los cambios relacionados con cada componente de una carga de trabajo. 

   1.  Permita que los cambios repetibles se estandaricen, se diseñen con plantillas y se autoricen previamente si siguen un flujo de trabajo coherente que aplique las políticas de cambio. 

   1.  Reduzca el impacto potencial de cualquier cambio mediante la reducción del tamaño del cambio para que la recuperación lleve menos tiempo y cause menos repercusión en la empresa. 

   1.  Asegúrese de que los procedimientos de reversión reviertan el código al estado correcto conocido para evitar incidentes siempre que sea posible. 

1.  Integre herramientas y flujos de trabajo para aplicar sus políticas mediante programación. 

1.  Haga que los datos sobre los cambios sean visibles para otros propietarios de cargas de trabajo para mejorar la velocidad de diagnóstico de cualquier cambio infructuoso que no se pueda revertir. 

   1.  Mida el éxito de esta práctica a través de datos de cambios visibles e identifique las mejoras iterativas. 

1.  Utilice herramientas de supervisión para verificar el éxito o el fracaso de una implementación a fin de acelerar la toma de decisiones sobre la reversión. 

1.  Mida la duración de la interrupción durante un cambio infructuoso para mejorar continuamente sus planes de recuperación. 

 **Nivel de esfuerzo para el plan de implementación:** medio 

## Recursos
Recursos

 **Prácticas recomendadas relacionadas:** 
+  [OPS06-BP04 Automatización de las pruebas y la reversión](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documentos relacionados:** 
+ [AWS Builders' Library: Asegurar la seguridad en las restauraciones durante las implementaciones ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [Documento técnico de AWS: Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)

 **Videos relacionados:** 
+ [ 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 Implementaciones de prueba
OPS06-BP02 Implementaciones de prueba

 Pruebe los procedimientos de lanzamiento en preproducción con la misma configuración de implementación, controles de seguridad, pasos y procedimientos que en producción. Valide que todos los pasos implementados se completen según lo esperado, como la inspección de archivos, configuraciones y servicios. Pruebe más a fondo todos los cambios con pruebas funcionales, de integración y de carga, junto con cualquier supervisión, como la comprobación de estado. Al llevar a cabo estas pruebas, puede identificar los problemas de implementación con prontitud y tiene la oportunidad de planificarlos y mitigarlos antes de llegar a producción. 

 Puede crear entornos paralelos temporales para probar cada cambio. Automatice la implementación de los entornos de prueba mediante la infraestructura como código (IaC) para reducir la cantidad de trabajo que implica y garantizar la estabilidad, la coherencia y una entrega de características más rápida. 

 **Resultado deseado:** su organización adopta una cultura de desarrollo basada en pruebas que incluye la implementación de pruebas. Esto garantiza que los equipos se centren en ofrecer valor empresarial en lugar de administrar las versiones. Los equipos participan desde el principio de la identificación de los riesgos de la implementación para determinar el curso de mitigación adecuado. 

 **Patrones comunes de uso no recomendados:** 
+  Durante las versiones de producción, las implementaciones no probadas provocan problemas frecuentes que requieren la solución de problemas y la escalada. 
+  Su versión contiene infraestructura como código (IaC) que actualiza los recursos existentes. No tiene la seguridad de si IaC se ejecuta correctamente o si afecta a los recursos. 
+  Implementa una característica nueva en su aplicación. No funciona según lo previsto y no hay visibilidad hasta que los usuarios afectados lo denuncien. 
+  Actualiza sus certificados. Instala accidentalmente los certificados en los componentes incorrectos, lo que pasa desapercibido y afecta a los visitantes del sitio web porque no se puede establecer una conexión segura con el sitio web. 

 **Beneficios de establecer esta práctica recomendada:** las exhaustivas pruebas en la preproducción de los procedimientos de implementación y los cambios introducidos por ellos minimizan la posible repercusión en producción causada por las etapas de implementación. Esto aumenta la confianza durante el lanzamiento de producción y minimiza el soporte operativo sin ralentizar la velocidad de los cambios que se introducen. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
Guía para la implementación

 Probar el proceso de implementación es tan importante como probar los cambios que resultan de la implementación. Esto se puede lograr probando los pasos de implementación en un entorno de preproducción que refleje la producción lo más fielmente posible. Los problemas más habituales, como pasos de implementación incompletos o incorrectos o configuraciones incorrectas, pueden detectarse antes de pasar a producción. Además, puede poner a prueba sus pasos de recuperación. 

 **Ejemplo de cliente** 

 Como parte de su canalización de integración y entrega continuas (CI/CD), AnyCompany Retail lleva a cabo los pasos definidos necesarios para lanzar actualizaciones de infraestructura y software para sus clientes en un entorno similar al de producción. La canalización se compone de comprobaciones previas para detectar desviaciones (detectar cambios en los recursos hechos fuera de su IaC) en los recursos antes de la implementación, así como para validar las acciones que la IaC emprende tras su inicio. Valida los pasos de la implementación, como verificar que determinados archivos y configuraciones estén en su sitio y que los servicios estén en estado de ejecución y respondan correctamente a las comprobaciones de estado del host local antes de volver a registrarse en el equilibrador de carga. Además, todos los cambios se someten a una serie de pruebas automatizadas, como pruebas funcionales, de seguridad, de regresión, de integración y de carga. 

### Pasos para la implementación
Pasos para la implementación

1.  Haga comprobaciones previas a la instalación para reflejar el entorno de preproducción en producción. 

   1.  Use la [detección de desviaciones](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) para detectar cuándo se han cambiado los recursos fuera de CloudFormation. 

   1.  Use los [conjuntos de cambio](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) para validar que la intención de una actualización de la pila coincida con las acciones que CloudFormation lleva a cabo cuando se inicia el conjunto de cambios. 

1.  Esto desencadena un paso de aprobación manual en [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) para autorizar la implementación en el entorno de preproducción. 

1.  Utilice configuraciones de implementación, como los archivos [AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html), para definir los pasos de implementación y validación. 

1.  Cuando proceda, [integre AWS CodeDeploy con otros servicios de AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) o [integre AWS CodeDeploy con los productos y servicios de los socios](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html). 

1.  [Supervise las implementaciones](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) mediante Amazon CloudWatch, AWS CloudTrail y las notificaciones de eventos de Amazon SNS. 

1.  Lleve a cabo pruebas automatizadas posteriores a la implementación, incluidas pruebas funcionales, de seguridad, de regresión, de integración y de carga. 

1.  [Solucione los problemas](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) de implementación. 

1.  La validación correcta de los pasos precedentes debería iniciar un flujo de trabajo de aprobación manual para autorizar la implementación en producción. 

 **Nivel de esfuerzo para el plan de implementación:** alto 

## Recursos
Recursos

 **Prácticas recomendadas relacionadas:** 
+  [OPS05-BP02 Prueba y validación de los cambios](ops_dev_integ_test_val_chg.md) 

 **Documentos relacionados:** 
+ [AWS Builders' Library: Automatización de implementaciones seguras y sin intervención \$1 Implementaciones de prueba ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [Documento técnico de AWS: Práctica de integración y entrega continuas en 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)
+  [How to test and debug AWS CodeDeploy locally before you ship your 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/)

 **Videos relacionados:** 
+ [ re:Invent 2020 \$1 Testing software and systems at Amazon ](https://www.youtube.com/watch?v=o1sc3cK9bMU)

 **Ejemplos relacionados:** 
+ [ Tutorial: Deploy and Amazon ECS service with a validation test ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)

# OPS06-BP03 Uso de estrategias de implementación seguras
OPS06-BP03 Uso de estrategias de implementación seguras

 Las implementaciones de producción seguras controlan el flujo de cambios beneficiosos con el objetivo de minimizar cualquier impacto percibido por los clientes como consecuencia de dichos cambios. Los controles de seguridad proporcionan mecanismos de inspección para validar los resultados deseados y limitar el alcance del impacto de cualquier defecto introducido por los cambios o por errores en la implementación. Las implementaciones seguras incluyen estrategias como: indicadores de características, caja individual, continuas (versiones de canarios), inmutables, división del tráfico e implementaciones azul-verde. 

 **Resultado deseado:** su organización utiliza un sistema de entrega continua e integración continua (CI/CD) que proporciona capacidades para automatizar implementaciones seguras. Los equipos deben utilizar estrategias adecuadas para implementaciones seguras. 

 **Patrones comunes de uso no recomendados:** 
+  Implementa un cambio sin éxito en toda la producción de una sola vez. Como resultado, todos los clientes resultan afectados simultáneamente. 
+  Un defecto introducido en una implementación simultánea en todos los sistemas requiere una versión de emergencia. Corregirlo para todos los clientes lleva varios días. 
+  La administración del lanzamiento de producción requiere la planificación y la participación de varios equipos. Esto limita su capacidad de actualizar con frecuencia las características para sus clientes. 
+  Lleva a cabo una implementación mutable al modificar los sistemas existentes. Tras descubrir que el cambio no ha tenido éxito, se ve obligado a modificar de nuevo los sistemas para restaurar la versión antigua, lo que prolonga el tiempo de recuperación. 

 **Beneficios de establecer esta práctica recomendada:** las implementaciones automatizadas equilibran la velocidad de las implementaciones con la entrega de cambios beneficiosos de manera coherente a los clientes. Limitar el impacto evita caros errores de implementación y maximiza la capacidad de los equipos de responder de manera eficiente a los errores. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
Guía para la implementación

 Los errores continuos en la entrega pueden provocar una reducción de la disponibilidad del servicio y una mala experiencia para los clientes. Para maximizar la tasa de implementaciones satisfactorias, implemente controles de seguridad en el proceso de lanzamiento de principio a fin de minimizar los errores de implementación, con el objetivo de lograr implementaciones sin ningún error. 

 **Ejemplo de cliente** 

 AnyCompany Retail tiene la misión de lograr implementaciones con un tiempo de inactividad mínimo o nulo, lo que significa que los usuarios no perciban ningún impacto durante las implementaciones. Para lograrlo, la empresa ha establecido patrones de implementación (consulte el siguiente diagrama de flujo de trabajo), como implementaciones azul-verde y continuas. Todos los equipos adoptan uno o más de estos patrones en su canalización de CI/CD. 


| Flujo de trabajo de CodeDeploy para Amazon EC2 | Flujo de trabajo de CodeDeploy para Amazon ECS | Flujo de trabajo de CodeDeploy para Lambda | 
| --- | --- | --- | 
|  ![\[Flujo de proceso de implementación para Amazon EC2\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/framework/images/deployment-process-ec2.png)  |  ![\[Flujo de proceso de implementación para Amazon ECS\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/framework/images/deployment-process-ecs.png)  |  ![\[Flujo de proceso de implementación para Lambda\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/framework/images/deployment-process-lambda.png)  | 

### Pasos para la implementación
Pasos para la implementación

1.  Use un flujo de trabajo de aprobación para iniciar la secuencia de pasos de implementación de producción, de la promoción a la producción. 

1.  Use un sistema de implementación automatizado como [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html). Las opciones de [implementaciones locales](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html) de AWS CodeDeploy para EC2/en las instalaciones e implementaciones azul-verde para EC2/en las instalaciones, AWS Lambda y Amazon ECS (consulte el diagrama de flujo de trabajo anterior). 

   1.  Cuando proceda, [integre AWS CodeDeploy con otros servicios de AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) o [integre AWS CodeDeploy con los productos y servicios de los socios](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html). 

1.  Utilice implementaciones azul/verde para bases de datos como [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) y [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html). 

1.  [Supervise las implementaciones](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) mediante Amazon CloudWatch, AWS CloudTrail y las notificaciones de eventos de Amazon Simple Notification Service (Amazon SNS). 

1.  Haga pruebas automatizadas posteriores a la implementación, incluidas pruebas funcionales, de seguridad, de regresión, de integración y cualquier prueba de carga. 

1.  [Solucione los problemas](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) de implementación. 

 **Nivel de esfuerzo para el plan de implementación:** medio 

## Recursos
Recursos

 **Prácticas recomendadas relacionadas:** 
+  [OPS05-BP02 Prueba y validación de los cambios](ops_dev_integ_test_val_chg.md) 
+  [OPS05-BP09 Cambios frecuentes, pequeños y reversibles](ops_dev_integ_freq_sm_rev_chg.md) 
+  [OPS05-BP10 Automatización completa de la integración y la implementación](ops_dev_integ_auto_integ_deploy.md) 

 **Documentos relacionados:** 
+ [AWS Builders' Library: Automatización de implementaciones seguras y sin intervención \$1 Implementaciones de producción ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library: My CI/CD pipeline is my release captain \$1 Safe, automatic production releases](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [Documento técnico de AWS: Práctica de integración y entrega continuas en AWS \$1 Métodos de implementación](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [AWS CodeDeploy Guía del usuario de](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)
+ [Configuración de una implementación de un lanzamiento canario de API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS Deployment Types](https://docs.aws.amazon.com/)
+ [Fully Managed Blue/Green Deployments in Amazon Aurora and 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)

 **Videos relacionados:** 
+ [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)

 **Ejemplos relacionados:** 
+ [Try a Sample Blue/Green Deployment in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [ Taller \$1 Building CI/CD pipelines for Lambda canary deployments using AWS CDK](https://catalog.workshops.aws/cdk-cicd-for-lambda-canary-deployment/en-US) 
+ [ Taller \$1 Building your first DevOps Blue/Green pipeline with Amazon ECS ](https://catalog.us-east-1.prod.workshops.aws/workshops/4b59b9fb-48b6-461c-9377-907b2e33c9df/en-US)
+ [ Taller \$1 Building your first DevOps Blue/Green pipeline with Amazon EKS ](https://catalog.us-east-1.prod.workshops.aws/workshops/4eab6682-09b2-43e5-93d4-1f58fd6cff6e/en-US)
+ [ Taller \$1 EKS GitOps with ArgoCD ](https://catalog.workshops.aws/eksgitops-argocd-githubactions)
+ [ Taller \$1 CI/CD on AWS Workshop ](https://catalog.workshops.aws/cicdonaws/en-US)
+ [ Implementing cross-account CI/CD with AWS SAM for container-based Lambda functions ](https://aws.amazon.com/blogs/compute/implementing-cross-account-cicd-with-aws-sam-for-container-based-lambda/)

# OPS06-BP04 Automatización de las pruebas y la reversión
OPS06-BP04 Automatización de las pruebas y la reversión

 Para aumentar la velocidad, la fiabilidad y la confianza de su proceso de implementación, tenga una estrategia para automatizar las capacidades de prueba y reversión en los entornos de preproducción y producción. Automatice las pruebas al implementar en producción para simular las interacciones entre humanos y sistemas que verifican los cambios que se implementan. Automatice la reversión para volver rápidamente a un estado válido anterior conocido. La reversión debe iniciarse automáticamente en condiciones predefinidas, como cuando no se logra el resultado deseado del cambio o cuando la prueba automatizada fracasa. La automatización de estas dos actividades mejora la tasa de éxito de las implementaciones, minimiza el tiempo de recuperación y reduce el impacto potencial en la empresa. 

 **Resultado deseado:** sus pruebas automatizadas y sus estrategias de reversión se integran en el proceso de integración y entrega continuas (CI/CD). Su supervisión puede validarse según sus criterios de éxito e iniciar una reversión automática en caso de error. Esto minimiza cualquier impacto en los usuarios finales y los clientes. Por ejemplo, cuando se satisfacen todos los resultados de las pruebas, promociona el código al entorno de producción donde se inician las pruebas de regresión automatizadas, mediante el uso de los mismos casos de prueba. Si los resultados de la prueba de regresión no coinciden con las expectativas, se inicia una reversión automática en el flujo de trabajo de la canalización. 

 **Patrones comunes de uso no recomendados:** 
+  Sus sistemas no tienen una arquitectura que permita actualizarlos con versiones más pequeñas. Como resultado, tiene dificultades para revertir esos cambios masivos durante una implementación infructuosa. 
+  El proceso de implementación consta de una serie de pasos manuales. Tras implementar los cambios en la carga de trabajo, se inician las pruebas posteriores a la implementación. Tras las pruebas, se da cuenta de que no puede utilizar la carga de trabajo y los clientes están desconectados. A continuación, empieza a revertir a la versión anterior. Todos estos pasos manuales retrasan la recuperación general del sistema y provocan un impacto prolongado en sus clientes. 
+  Ha dedicado tiempo a desarrollar casos de prueba automatizados para funciones que no se utilizan con frecuencia en su aplicación, lo que minimiza el retorno de la inversión en su capacidad de llevar a cabo pruebas automatizadas. 
+  Su versión se compone de actualizaciones de aplicaciones, infraestructura, parches y configuración que son independientes entre sí. Sin embargo, tiene una única canalización de CI/CD que introduce todos los cambios a la vez. Un error en un componente le obliga a revertir todos los cambios, lo que hace que la reversión sea compleja e ineficiente. 
+  Su equipo completa el trabajo de codificación en el primer sprint y comienza el trabajo en el segundo, pero el plan no incluía las pruebas hasta el tercer sprint. Como resultado, las pruebas automatizadas revelaron defectos en el primer sprint que tenían que haberse resuelto antes de empezar a probar los resultados del segundo sprint, con lo que se retrasa todo el lanzamiento y se devalúan las pruebas automatizadas. 
+  Los casos de las pruebas de regresión automatizadas para el lanzamiento de producción se han completado, pero no está supervisando el estado de la carga de trabajo. Como no puede saber si el servicio se ha reiniciado o no, no está seguro de si es necesaria una reversión o si ya se ha producido. 

 **Beneficios de establecer esta práctica recomendada:** las pruebas automatizadas aumentan la transparencia del proceso de pruebas y su capacidad para abarcar más características en un intervalo más reducido. Al probar y validar los cambios en la producción, puede identificar los problemas de forma inmediata. La mejora de la coherencia con herramientas de prueba automatizadas permite una mejor detección de los defectos. Al revertir automáticamente a la versión anterior, se minimiza el impacto en los clientes. La reversión automatizada, en última instancia, inspira más confianza en sus capacidades de implementación al reducir el impacto empresarial. En general, estas capacidades reducen el tiempo de entrega y, al mismo tiempo, garantizan la calidad. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
Guía para la implementación

 Automatice las pruebas de los entornos implementados para confirmar los resultados deseados con más rapidez. Automatice la reversión a un estado conocido correcto anterior cuando no se logren resultados predefinidos para minimizar el tiempo de recuperación y reducir los errores causados por los procesos manuales. Integre las herramientas de prueba con el flujo de trabajo de la canalización para probar y minimizar las entradas manuales de manera coherente. Priorice la automatización de los casos de prueba, como aquellos que mitigan los mayores riesgos y que deben probarse con frecuencia con cada cambio. Esto le ayuda a medir el retorno de la inversión (ROI) y da a los propietarios de cargas de trabajo la oportunidad de optimizar sus recursos y reducir costos. 

### Pasos para la implementación
Pasos para la implementación

1.  Establezca un ciclo de vida de pruebas para su ciclo de vida de desarrollo que defina cada etapa del proceso de prueba, desde la planificación de los requisitos hasta el desarrollo de los casos de prueba, la configuración de las herramientas, las pruebas automatizadas y el cierre de los casos de prueba. 

   1.  Cree un enfoque de pruebas específico para la carga de trabajo a partir de su estrategia general de pruebas. 

   1.  Considere una estrategia de pruebas continuas cuando sea apropiado durante todo el ciclo de vida de desarrollo. 

1.  Seleccione herramientas automatizadas para efectuar pruebas y reversiones en función de sus requisitos empresariales y de las inversiones en curso. 

1.  Decida qué casos de prueba quiere automatizar y cuáles se deberán llevar a cabo manualmente. Estos se pueden definir en función de la prioridad de valor empresarial de la característica que se está probando. Alinee a todos los miembros del equipo con este plan y verifique la responsabilidad de efectuar las pruebas manuales. 

   1.  Aplique capacidades de pruebas automatizadas a casos de prueba específicos que tengan sentido para la automatización, como los casos repetibles o que se ejecutan con frecuencia, los que requieren tareas repetitivas o los que se requieren en varias configuraciones. 

   1.  Defina los scripts de automatización de pruebas, así como los criterios de éxito en la herramienta de automatización, de modo que se pueda iniciar la automatización continua del flujo de trabajo cuando fracasan casos específicos. 

   1.  Defina criterios de error concretos para la reversión automática. 

1.  Priorice la automatización de las pruebas para obtener resultados coherentes con un desarrollo exhaustivo de casos de prueba en los que la complejidad y la interacción humana tengan un mayor riesgo de fracaso. 

1.  Integre las herramientas automatizadas de pruebas y reversión en la canalización de CI/CD. 

   1.  Desarrolle criterios de éxito claros para los cambios. 

   1.  Supervise y observe para detectar estos criterios y revertir automáticamente los cambios cuando se cumplan criterios de reversión específicos. 

1.  Lleve a cabo diferentes tipos de pruebas automatizadas de producción, como: 

   1.  Pruebas A/B para mostrar los resultados en comparación con la versión actual entre dos grupos de pruebas de usuarios. 

   1.  Pruebas canario que permiten implementar el cambio en un subconjunto de usuarios antes de lanzarlo para todos. 

   1.  Pruebas de marca de características que permiten activar y desactivar las características de la nueva versión de una en una desde fuera de la aplicación para que cada característica nueva se pueda validar por sí sola. 

   1.  Pruebas de regresión para verificar la nueva funcionalidad con los componentes interrelacionados ya existentes. 

1.  Supervise los aspectos operativos de la aplicación, las transacciones y las interacciones con otras aplicaciones y componentes. Redacte informes que muestren el éxito de los cambios por carga de trabajo, de modo que pueda identificar qué partes de la automatización y el flujo de trabajo se pueden optimizar aún más. 

   1.  Elabore informes de resultados de pruebas que le ayuden a tomar decisiones rápidas sobre si se deben invocar o no los procedimientos de reversión. 

   1.  Implemente una estrategia que permita la reversión automática en función de condiciones de error predefinidas que resulten de uno o más de sus métodos de prueba. 

1.  Desarrolle los casos de prueba automatizados para poder volver a usarlos en futuros cambios repetibles. 

 **Nivel de esfuerzo para el plan de implementación:** medio 

## Recursos
Recursos

 **Prácticas recomendadas relacionadas:** 
+  [OPS06-BP01 Planificación para hacer frente a los cambios infructuosos](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) 
+  [OPS06-BP02 Implementaciones de prueba](ops_mit_deploy_risks_test_val_chg.md) 

 **Documentos relacionados:** 
+ [AWS Builders' Library: Asegurar la seguridad en las restauraciones durante las implementaciones ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+  [Redeploy and rollback a deployment with AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html) 
+ [ 8 best practices when automating your deployments with AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)

 **Ejemplos relacionados:** 
+ [ Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools ](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)

 **Videos relacionados:** 
+ [ 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)