# OPS06-BP04 自动测试和回滚
<a name="ops_mit_deploy_risks_auto_testing_and_rollback"></a>

 为了提高部署过程的速度和可靠性以及对该过程的信心，需要制定一项策略，用于在预生产环境和生产环境中实现自动化的测试和回滚功能。在部署到生产环境时自动进行测试，模拟人与系统的交互，从而验证已经部署的更改。利用自动回滚功能，可以快速恢复到先前已知的良好状态。回滚应在预先定义的条件下自动启动，例如更改未达到期望结果或自动化测试失败时。自动执行这两项活动可以提高部署的成功率，尽可能缩短恢复时间，并减少可能对业务造成的影响。

 **期望结果：**自动化测试和回滚策略已集成到持续集成/持续交付（CI/CD）管道中。监控功能可以根据成功标准进行验证，并能在失败时启动自动回滚。这样可以最大限度地减少对终端用户和客户的任何影响。例如，对所有测试结果都感到满意时，可以将代码提升到生产环境中，该环境启动了使用相同测试案例的自动回归测试。如果回归测试结果与预期不符，则在管道工作流程中启动自动回滚。

 **常见反模式：**
+  系统的架构不允许使用较小的发布版本进行更新。因此，在部署失败时，很难撤销这些大批量的更改。
+  部署流程包括一系列手动步骤。将更改部署到工作负载后，启动部署后测试。完成测试之后，发现工作负载不可操作，而且客户断开了连接。然后，开始回滚到之前的版本。所有这些手动步骤都会延误整个系统的恢复，并对客户造成长时间的影响。
+  花时间为应用程序中不常用的功能开发了自动化测试案例，这极大地降低了在自动化测试功能上的投资回报率。
+  发布版本由应用程序、基础设施、补丁和配置更新组成，这些组件相互独立。但是，只有一个 CI/CD 管道，只能同时交付所有更改。一个组件中的失败会迫使撤销所有更改，导致回滚过程复杂且效率低下。
+  团队完成了冲刺一的编码工作并开始冲刺二的工作，但是按照计划，直到冲刺三才会进行测试。结果，自动化测试发现冲刺一中存在缺陷，必须先解决这些缺陷，才能开始测试冲刺二的可交付成果，这延误了整个发布过程，大大降低了自动化测试的价值。
+  生产版本的自动化回归测试案例已完成，但没有监控工作负载运行状况。由于无法监控服务是否已重新启动，因此不确定是否需要回滚或者是否已经进行了回滚。

 **建立此最佳实践的好处：**自动化测试可提高测试过程的透明度，以及在更短的时间内测试更多功能的能力。通过对生产环境中的更改进行测试和验证，可以立即发现问题。利用自动化测试工具改进一致性，可以更好地检测缺陷。通过自动回滚到之前的版本，可以将对客户的影响降至最低。自动回滚可以减少业务影响，最终提升对部署功能的信心。总体而言，这些功能可在确保质量的同时缩短交付时间。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

 自动测试部署的环境，以便更快地确认期望结果。在没有达到预定义的结果时，自动回滚到之前的已知良好状态，尽可能地缩短恢复时间，并减少手动流程导致的错误。将测试工具与管道工作流程集成，以便一致地开展测试并尽可能减少手动输入。确定优先执行的自动化测试案例，例如能够降低最大风险的测试案例，以及每次更改都需要频繁测试的测试案例。此外，还可以根据在测试计划中预定义的特定条件自动回滚。

### 实施步骤
<a name="implementation-steps"></a>

1.  为开发生命周期建立测试生命周期，针对测试过程，从需求规划到测试案例开发、工具配置、自动化测试和测试案例关闭，对每个阶段进行定义。

   1.  根据整体测试策略，创建特定于工作负载的测试方法。

   1.  考虑在整个开发生命周期中适宜的阶段实施持续测试策略。

1.  根据业务要求和管道投资，选择用于测试和回滚的自动化工具。

1.  确定要自动执行哪些测试案例，以及应手动执行哪些测试案例。这个过程可以根据所测试功能的业务价值优先级来定义。确保所有团队成员都遵守该计划，并核实执行手动测试的责任人。

   1.  在自动化测试可以实现价值的特定测试案例上使用自动化测试功能，例如可重复或经常运行的案例、需要重复任务的案例或者多种配置中所需的案例。

   1.  在自动化工具中定义测试自动化脚本和成功标准，以便在特定案例失败时可以启动持续的自动化工作流程。

   1.  为自动回滚定义具体的失败标准。

1.  优先考虑测试自动化，在过于复杂和人工交互会导致更高失败风险的案例中，通过开发全面的测试案例来获得一致的结果。

1.  将自动化测试和回滚工具集成到 CI/CD 管道中。

   1.  为更改制定明确的成功标准。

   1.  监控并观察以便检测这些标准，以及在满足特定回滚标准时自动撤销更改。

1.  执行不同类型的自动化生产测试，例如：

   1.  A/B 测试，显示在两个用户测试组之间当前版本的结果对比。

   1.  金丝雀测试，允许先对一部分用户部署更改，然后再向所有用户发布。

   1.  功能标记测试，允许在应用程序外部，每次将新版本的单个功能标记为打开和关闭，以便每次逐个验证各个新功能。

   1.  回归测试，用于验证现有相互关联组件的新功能。

1.  监控应用程序的操作情况、事务，以及与其他应用程序和组件的交互。编制报告，用于按工作负载显示更改是否成功，以便确定对自动化和工作流程的哪些部分进一步进行优化。

   1.  编制测试结果报告，以便快速决定是否应调用回滚程序。

   1.  实施策略，以便根据一种或多种测试方法的预定义失败条件进行自动回滚。

1.  开发自动化测试案例，以便在将来的可重复更改中重用。

 **实施计划的工作量级别：**中 

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+  [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) 
+  [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md) 

 **相关文档：**
+ [AWS Builders Library \$1 确保部署期间安全回滚](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/)

 **相关示例：**
+ [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/)

 **相关视频：**
+ [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)