# OPS 6. 如何缓解部署风险？
采用的方法需能够提供快速质量反馈，并在更改没有达到预期结果时实现快速恢复。使用这些实践可以减轻因部署更改而产生的问题的影响。
**Topics**
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 采用安全部署策略](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 针对不成功的更改制定计划
制定计划，以便在部署没有达到期望结果时，在生产环境中恢复到已知良好状态，或者进行修复。制定一项策略来建立这样的计划，有助于所有团队制定从失败的更改中恢复的策略。这样的示例策略包括部署和回滚步骤、更改策略、功能标记、流量隔离和流量转移。单个发布版本可能包括多个相关的组件更改。该策略应提供承受任何组件更改的失败或从中恢复过来的能力。
**期望结果：**已为更改失败准备了详细的恢复计划。此外，还缩小了发布内容的大小，以便最大限度地减少对其他工作负载组件的潜在影响。因此，通过缩短更改失败可能造成的停机时间，提高恢复时间的灵活性和效率，减少了对业务的影响。
**常见反模式：**
+ 执行部署后，应用程序变得不稳定，但是系统上似乎还有活动用户。您必须决定是回滚更改并影响活动用户，还是等到知道用户无论如何都可能受到影响后再回滚更改。
+ 执行例行更改后，可以访问新环境，但是无法访问其中一个子网。必须决定是回滚所有内容还是尝试修复无法访问的子网。做决定时，子网仍然无法访问。
+ 系统的架构不允许使用较小的发布版本进行更新。因此，在部署失败时，很难撤销这些大批量的更改。
+ 没有使用基础设施即代码（IaC）模式，而且对基础设施进行的手动更新导致了不希望出现的配置。无法有效地跟踪和撤销手动更改。
+ 由于没有将部署频率的增加作为衡量标准，因此团队没有动力来缩小更改规模，也不愿意改进每次更改的回滚计划，从而导致风险增加和失败率上升。
+ 没有衡量因更改失败而导致的中断的总持续时间。团队无法确定部署流程的优先顺序和恢复计划的有效性，也无法进行改进。
**建立此最佳实践的好处：**制定从失败更改中恢复的计划可以最大限度地缩短平均恢复时间（MTTR），并减少对业务的影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
发布团队采用的一致、有据可查的策略和实践，让组织能够计划在更改失败时应如何处理。该策略应允许在特定情况下向前修复。无论是哪种情况，在部署到实际生产环境之前，都应妥善记录并测试向前修复或回滚计划，以便最大限度地减少从更改中恢复所需的时间。
### 实施步骤
1. 记录策略，该策略要求团队制定有效计划以便在指定时间内撤销更改。
1. 策略应指定何时允许出现向前修复的情况。
1. 要求所有相关人员都能查阅记录在案的回滚计划。
1. 指定回滚要求（例如，当发现部署了未经授权的更改时）。
1. 分析与工作负载每个组件相关的所有更改的影响级别。
1. 如果可重复的更改遵循的工作流程，与执行更改策略的工作流程保持一致，则允许对这些更改进行标准化、模板化和预授权。
1. 通过缩小更改的规模来减少任何更改的潜在影响，从而减少恢复所需的时间和对业务的影响。
1. 确保回滚程序将代码恢复到已知的良好状态，尽可能避免意外事件。
1. 集成工具和工作流程，以编程方式执行策略。
1. 让其他工作负载所有者能够查看有关更改的数据，以便提高对无法回滚的任何失败更改的诊断速度。
1. 利用可见的更改数据来衡量这一做法是否成功，并确定迭代改进措施。
1. 使用监控工具来验证部署的成败，从而加快制定回滚决策的速度。
1. 衡量更改失败时的停机时间，以便不断改进恢复计划。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [AWS Builders Library \$1 确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS 白皮书 \$1 Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**相关视频：**
+ [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 测试部署
使用与生产环境相同的部署配置、安全控制、步骤和程序，在预生产环境中测试发布程序。验证所有部署步骤是否按预期完成，如检查文件、配置和服务。通过功能测试、集成测试和负载测试以及运行状况检查等各种监控方法，进一步测试所有更改。通过这些测试，可以及早发现部署问题，并有机会在进入生产之前规划和缓解问题。
可以创建临时的并行环境来测试每项更改。使用基础设施即代码（IaC）自动部署测试环境，有助于减少所涉及的工作量，确保稳定性、一致性和更快的功能交付。
**期望结果：**组织采用了包含测试部署在内的测试驱动型开发文化。这样可以确保团队专注于实现业务价值，而不是管理发布版本。各团队在发现部署风险后尽早参与进来，确定适当的缓解方案。
**常见反模式：**
+ 在发布生产版本期间，未经测试的部署会导致问题频发，需要进行故障排除和上报。
+ 发布版本包含用于更新现有资源的基础设施即代码（IaC）。不确定 IaC 是会成功运行，还是会对资源造成影响。
+ 在应用程序中部署一项新功能。此功能未按预期运行，并且在受影响的用户报告之前都无从了解问题。
+ 您更新了证书。您不小心将证书安装到了错误的组件上，而这却没有被发现，于是因为无法建立与网站的安全连接而影响网站访客。
**建立此最佳实践的好处：**在预生产环境中对部署程序及其引入的更改进行全面测试，可最大限度地减少部署步骤对生产的潜在影响。这增强了生产版本发布过程中的信心，并最大限度地减少了运营支持，而且不会减慢更改交付速度。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
测试部署过程与测试部署所产生的更改同样重要。要完成这一步骤，可以在尽可能接近生产环境的预生产环境中测试部署步骤。可以在投入生产之前发现一些常见问题，如部署步骤不完整、不正确或配置错误。此外，还可以测试恢复步骤。
**客户示例**
作为持续集成和持续交付（CI/CD）管道的一部分，AnyCompany Retail 在类似生产的环境中执行为客户发布基础设施和软件更新所需的既定步骤。该管道包含预检查过程，用于在部署之前检测资源中的偏差（检测在 IaC 之外对资源执行的更改），以及验证 IaC 在启动时采取的操作。该管道会验证部署步骤，例如在向负载均衡器重新注册之前，验证特定文件和配置是否已准备就绪，服务是否处于正在运行状态，以及是否正确响应本地主机上的运行状况检查。此外，所有更改都要进行一系列自动测试，如功能测试、安全测试、回归测试、集成测试和负载测试。
### 实施步骤
1. 执行预安装检查，模拟生产环境打造预生产环境。
1. 使用[偏差检测](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)功能，检测是否在 CloudFormation 之外更改了资源。
1. 使用[更改集](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html)功能，验证堆栈更新的意图是否与 CloudFormation 在启动更改集时所采取的操作相匹配。
1. 这会触发 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) 中的手动批准步骤，以授权部署到预生产环境。
1. 使用 [AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) 文件等部署配置来定义部署和验证步骤。
1. 在适用的情况下，[将 AWS CodeDeploy 与其他 AWS 服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或[将 AWS CodeDeploy 与合作伙伴的产品和服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)。
1. 使用 Amazon CloudWatch、AWS CloudTrail 和 Amazon SNS 事件通知[监控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 执行部署后的自动化测试，包括功能测试、安全测试、回归测试、集成测试和负载测试。
1. 部署问题[疑难解答](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
1. 成功验证上述步骤后应启动手动审批工作流程，授权部署到生产环境。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [OPS05-BP02 测试并验证更改](ops_dev_integ_test_val_chg.md)
**相关文档：**
+ [AWS Builders' Library \$1 自动实现无需干预的安全部署 \$1 测试部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS 白皮书 \$1 在 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/)
**相关视频：**
+ [re:Invent 2020 \$1 Testing software and systems at Amazon](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**相关示例：**
+ [Tutorial \$1 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 采用安全部署策略
在安全的生产环境滚动部署中，会对有益更改的流程进行控制，目标是尽可能减少这些更改让客户感知到的任何影响。安全控制措施提供检查机制，用于验证是否达成期望结果，并针对由于更改或部署失败所引入的任何缺陷，限制这些缺陷的影响范围。安全滚动部署可包括功能标记、单盒、滚动（金丝雀版本）、不可变、流量分割和蓝绿部署等策略。
**期望结果：**组织使用持续集成/持续交付（CI/CD）系统，提供自动进行安全滚动部署的功能。团队必须使用适当的安全滚动部署策略。
**常见反模式：**
+ 将不成功的更改一次性部署到所有生产环境中。因此，所有客户同时受到影响。
+ 在同时部署到所有系统时，引入的缺陷需要紧急进行修复。为所有客户修复该缺陷需要几天时间。
+ 管理生产版本发布需要多个团队的规划和参与。这限制了为客户更新功能的频率。
+ 通过修改现有系统来执行可变部署。发现更改不成功后，被迫再次修改系统，还原旧版本，导致恢复时间延长。
**建立此最佳实践的好处：**自动化的部署，在快速滚动部署与持续向客户提供有益更改之间取得平衡。限制影响范围可以防止代价高昂的部署失败，并最大限度地提高团队有效应对失败的能力。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
持续交付失败会导致服务可用性降低，带来糟糕的客户体验。为了最大限度地提高部署成功率，请在端到端发布流程中实施安全控制措施，以便最大限度地减少部署错误，以达成零部署失败为目标。
**客户示例**
AnyCompany Retail 的目标是尽可能减少部署的停机时间，甚至实现零停机，这意味着在部署期间，不会对用户造成任何可察觉影响。为了实现这一目标，公司建立了部署模式（参阅以下工作流程图），例如滚动部署和蓝绿部署。所有团队在各自的 CI/CD 管道中都采用了其中一种或多种模式。
| 适用于 Amazon EC2 的 CodeDeploy 工作流程 | 适用于 Amazon ECS 的 CodeDeploy 工作流程 | 适用于 Lambda 的 CodeDeploy 工作流程 |
| --- | --- | --- |
| ![\[适用于 Amazon EC2 的部署流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-process-ec2.png) | ![\[适用于 Amazon ECS 的部署流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-process-ecs.png) | ![\[适用于 Lambda 的部署流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-process-lambda.png) |
### 实施步骤
1. 使用审批工作流程在提升到生产版本后，启动生产版本滚动部署步骤序列。
1. 使用 [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 等自动化部署系统。AWS CodeDeploy [部署选项](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html)包括 EC2/本地就地部署及 EC2/本地蓝绿部署、AWS Lambda 和 Amazon ECS（参阅前面的工作流程图）。
1. 在适用的情况下，[将 AWS CodeDeploy 与其他 AWS 服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或[将 AWS CodeDeploy 与合作伙伴的产品和服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)。
1. 对诸如 [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) 和 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) 之类的数据库使用蓝/绿部署。
1. 使用 Amazon CloudWatch、AWS CloudTrail 和 Amazon Simple Notification Service（Amazon SNS）[监控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 执行部署后的自动化测试，包括功能测试、安全测试、回归测试、集成测试以及任何负载测试。
1. 部署问题[疑难解答](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS05-BP02 测试并验证更改](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP09 频繁进行可逆的小规模更改](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 完全自动化集成和部署](ops_dev_integ_auto_integ_deploy.md)
**相关文档：**
+ [AWS Builders Library \$1 自动实现无需干预的安全部署 \$1 生产部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library \$1 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)
+ [AWS 白皮书 \$1 在 AWS 上练习持续集成和持续交付 \$1 部署方法](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [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)
+ [设置 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)
**相关视频：**
+ [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)
**相关示例：**
+ [Try a Sample Blue/Green Deployment in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [ Workshop \$1 Building CI/CD pipelines for Lambda canary deployments using AWS CDK](https://catalog.workshops.aws/cdk-cicd-for-lambda-canary-deployment/en-US)
+ [ Workshop \$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)
+ [ Workshop \$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)
+ [ Workshop \$1 EKS GitOps with ArgoCD ](https://catalog.workshops.aws/eksgitops-argocd-githubactions)
+ [ Workshop \$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 自动测试和回滚
为了提高部署过程的速度和可靠性以及对该过程的信心，需要制定一项策略，用于在预生产环境和生产环境中实现自动化的测试和回滚功能。在部署到生产环境时自动进行测试，模拟人与系统的交互，从而验证已经部署的更改。利用自动回滚功能，可以快速恢复到先前已知的良好状态。回滚应在预先定义的条件下自动启动，例如更改未达到期望结果或自动化测试失败时。自动执行这两项活动可以提高部署的成功率，尽可能缩短恢复时间，并减少可能对业务造成的影响。
**期望结果：**自动化测试和回滚策略已集成到持续集成/持续交付（CI/CD）管道中。监控功能可以根据成功标准进行验证，并能在失败时启动自动回滚。这样可以最大限度地减少对终端用户和客户的任何影响。例如，对所有测试结果都感到满意时，可以将代码提升到生产环境中，该环境启动了使用相同测试案例的自动回归测试。如果回归测试结果与预期不符，则在管道工作流程中启动自动回滚。
**常见反模式：**
+ 系统的架构不允许使用较小的发布版本进行更新。因此，在部署失败时，很难撤销这些大批量的更改。
+ 部署流程包括一系列手动步骤。将更改部署到工作负载后，启动部署后测试。完成测试之后，发现工作负载不可操作，而且客户断开了连接。然后，开始回滚到之前的版本。所有这些手动步骤都会延误整个系统的恢复，并对客户造成长时间的影响。
+ 花时间为应用程序中不常用的功能开发了自动化测试案例，这极大地降低了在自动化测试功能上的投资回报率。
+ 发布版本由应用程序、基础设施、补丁和配置更新组成，这些组件相互独立。但是，只有一个 CI/CD 管道，只能同时交付所有更改。一个组件中的失败会迫使撤销所有更改，导致回滚过程复杂且效率低下。
+ 团队完成了冲刺一的编码工作并开始冲刺二的工作，但是按照计划，直到冲刺三才会进行测试。结果，自动化测试发现冲刺一中存在缺陷，必须先解决这些缺陷，才能开始测试冲刺二的可交付成果，这延误了整个发布过程，大大降低了自动化测试的价值。
+ 生产版本的自动化回归测试案例已完成，但没有监控工作负载运行状况。由于无法监控服务是否已重新启动，因此不确定是否需要回滚或者是否已经进行了回滚。
**建立此最佳实践的好处：**自动化测试可提高测试过程的透明度，以及在更短的时间内测试更多功能的能力。通过对生产环境中的更改进行测试和验证，可以立即发现问题。利用自动化测试工具改进一致性，可以更好地检测缺陷。通过自动回滚到之前的版本，可以将对客户的影响降至最低。自动回滚可以减少业务影响，最终提升对部署功能的信心。总体而言，这些功能可在确保质量的同时缩短交付时间。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
自动测试部署的环境，以便更快地确认期望结果。在没有达到预定义的结果时，自动回滚到之前的已知良好状态，尽可能地缩短恢复时间，并减少手动流程导致的错误。将测试工具与管道工作流程集成，以便一致地开展测试并尽可能减少手动输入。确定优先执行的自动化测试案例，例如能够降低最大风险的测试案例，以及每次更改都需要频繁测试的测试案例。此外，还可以根据在测试计划中预定义的特定条件自动回滚。
### 实施步骤
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. 开发自动化测试案例，以便在将来的可重复更改中重用。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [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)