

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 使用和自动进行动态管道管理，以便在 Gitflow 环境中部署修补程序解决方案 AWS Service Catalog AWS CodePipeline
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions"></a>

*Balaji Vedagiri、Faisal Shahdad、Shanmugam Shanker 和 Vivek Thangamuthu，Amazon Web Services*

## Summary
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-summary"></a>

**注意**  
AWS CodeCommit 不再向新客户提供。的现有客户 AWS CodeCommit 可以继续照常使用该服务。[了解详情](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider)

此模式适用于管理专门用于将修补程序解决方案安全地部署到生产环境的动态修补程序管道的情况。该解决方案是通过使用产品 AWS Service Catalog 组合和产品来实施和管理的。Amazon EventBridge 规则用于事件自动化。使用 Service Catalog 产品组合约束以及开发人员的 AWS Identity and Access Management （IAM）角色强制执行限制。只有一个 AWS Lambda 函数可以启动由 EventBridge 规则触发的 Service Catalog 产品。此模式专为采用特定 Gitflow 设置的环境而设计，详见[附加信息](#automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-additional)。

通常，部署修补程序是为了解决在实时环境（例如生产）中报告的关键问题或安全问题。修补程序应当仅直接部署到暂存和生产环境。暂存和生产管道广泛用于常规开发请求。这些管道不能用于部署修补程序，因为质量保证中有一些在研功能无法部署到生产中。为了发布修补程序，该模式描述了具有以下安全功能的动态、短暂的管道：
+ **自动创建**-每当在存储库中创建修补程序分支时，都会自动创建修补程序管道。 AWS CodeCommit 
+ **访问限制** - 开发人员无权在修补程序流程之外创建此管道。
+ **受控阶段** – 管道具有使用特殊访问令牌的受控阶段，确保拉取请求（PR）只能创建一次。
+ **审批阶段** – 审批阶段包括在该管道中，以获得相关干系人的必要审批。
+ **自动删除**-每当仓库中的分支与 PR 合并后，只要删除 CodeCommit 存储库中的`hotfix`分支，就会自动删除该修补程序管道。

## 先决条件和限制
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-prereqs"></a>

**先决条件**
+ 需要三个 AWS 账户 处于活动状态，如下所示：
  + 工具账户 - 用于持续集成和持续交付（CI/CD）设置。
  + 暂存账户 - 用于用户验收测试。
  + 生产账户 - 用于企业最终用户。
  + （可选）添加一个 AWS 账户 以充当 QA 帐户。如果您想要同时使用主管道设置（包括 QA）和修补程序管道解决方案进行测试，则需要此账户。
+ 具有可选条件的 AWS CloudFormation 堆栈，可根据需要使用主管道在 QA 账户中部署。通过创建和删除 `hotfix` 分支，仍然可以在没有主管道设置的情况下测试该模式。
+ 亚马逊简单存储服务 (Amazon S3) 存储桶，用于存储 CloudFormation 用于创建服务目录产品的模板。
+ 根据合规性要求为 CodeCommit 存储库创建 PR 批准规则（在创建存储库之后）。
+ 限制开发人员和团队负责人的 IAM 权限以禁止其执行 [prcreation-lambda](https://github.com/aws-samples/dynamic_hotfix_codepipeline/blob/main/pre-requisites/lambdasetup.yaml#L55) Lambda 函数，因为该函数仅应从管道中调用。

**限制**
+ 在部署阶段使用 CloudFormation 提供程序，使用 CloudFormation 更改集部署应用程序。如果要使用其他部署选项，请根据需要修改 CodePipeline 堆栈。
+ 此模式使用 AWS CodeBuild 和其他配置文件来部署示例微服务。如果您有不同的工作负载类型（例如，无服务器工作负载），则必须更新所有相关配置。
+ 这种模式将应用程序部署在单个 AWS 区域 （例如，美国东部（弗吉尼亚北部）us-east-1）中。 AWS 账户要跨多个区域进行部署，请更改命令和堆栈中的区域引用。
+ 有些 AWS 服务 并非全部可用 AWS 区域。有关区域可用性，请参阅[按区域划分的 AWS 服务](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)。有关特定端点，请参阅[服务端点和配额](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)，然后选择相应服务的链接。

## 架构
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-architecture"></a>

本节中的图表提供了创建生命周期事件和删除生命周期事件的工作流。

![创建生命周期事件的工作流。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/images/pattern-img/64311acc-8c0f-4734-aa1b-74345d86c752/images/3939f77c-4221-4c23-a3a1-3e8a294b2b32.png)


上面创建生命周期事件的图表显示了以下内容：

1. 开发人员在 CodeCommit 存储库中创建一个`hotfix-*`分支来开发与 hotfix 相关的解决方案。

1. 分`hotfix-*`支创建事件是通过 EventBridge 规则捕获的。事件详细信息包括存储库名称和分支名称。

1. 该 EventBridge 规则调用该函数。 AWS Lambda `hotfix-lambda-function`该 EventBridge 规则将事件信息作为输入传递给 Lambda 函数。

1. Lambda 函数处理输入以检索存储库名称和分支名称。它使用从处理的输入中检索到的值启动 Service Catalog 产品。

1. Service Catalog 产品包括将解决方案部署到预发布和生产环境的管道设置。管道块包括源、构建和部署阶段。此外，还有一个手动批准阶段，可以促进生产环境的部署。

1. 源阶段从第一步中创建的存储库和 `hotfix-*` 分支检索代码。该代码通过用于存放构件的 Amazon S3 存储桶传递到构建阶段。在构建阶段，将创建一个容器映像，其中包含在 `hotfix-*` 分支中开发并推送到 Amazon Elastic Container Registry（Amazon ECR）中的修补程序。

1. 预发布环境的部署阶段使用包含此修补程序的最新容器映像更新 Amazon Elastic Container Service（Amazon ECS）。此修补程序是通过创建和执行 CloudFormation 更改集来部署的。

1. 在 Stage 环境中成功部署后调用 `prcreation-lambda` Lambda 函数。此 Lambda 函数创建从 `hotfix-*` 分支到存储库 `develop` 和 `main` 分支的 PR。Lambda 函数可确保 `hotfix-*` 分支中开发的修复程序被回溯并包含在后续部署中。

1. 手动批准阶段有助于确保必要的利益相关者审核该修复并批准在生产环境中部署。

1. 生产环境的部署阶段使用包含此修补程序的最新容器映像更新 Amazon ECS。此修补程序是通过创建和执行 CloudFormation 更改集来部署的。

![删除生命周期事件的工作流。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/images/pattern-img/64311acc-8c0f-4734-aa1b-74345d86c752/images/192aa897-bd9b-4a9f-804e-340371612b3b.png)


上面删除生命周期事件的图表显示了以下内容：

1. 成功将修补程序部署到生产环境后，开发人员会删除该 `hotfix-*` 分支。

1. 分`hotfix-*`支删除事件是通过 EventBridge 规则捕获的。事件详细信息包括存储库名称和分支名称。

1. 该 EventBridge 规则调用 Lambda 函数。该 EventBridge 规则将事件信息作为输入传递给 Lambda 函数。

1. Lambda 函数处理输入以检索存储库名称和分支名称。Lambda 函数根据传递的输入确定相应的 Service Catalog 产品，然后终止该产品。

1. Service Catalog 预调配的产品终止会删除之前在该产品中创建的管道和相关资源。

**自动化和扩展**
+ 该模式包括一个 EventBridge 规则和一个 Lambda 函数，它们可以并行处理多个修补程序分支创建请求。Lambda 函数为匹配的事件规则预调配 Service Catalog 产品。
+ 管道设置通过使用提供版本控制功能的 Service Catalog 产品来处理。该解决方案还可以自动扩展，以并行处理同一应用程序的多个修补程序开发。
+ [prcreation-lambda](https://github.com/aws-samples/dynamic_hotfix_codepipeline/blob/main/pre-requisites/lambdasetup.yaml#L55) 函数可确保通过自动创建拉取请求，将这些修补程序更改合并回 `main` 和 `develop` 分支中。这种方法对于确保 `main` 和 `develop` 分支及时同步所有修复内容并避免潜在的代码回归至关重要。此过程通过确保所有长期存在的分支获得了最新的修复程序，有助于保持分支之间的一致性，并防止代码回归。

## 工具
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-tools"></a>

**AWS 服务**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)帮助您设置 AWS 资源，快速一致地配置资源，并在和的整个 AWS 账户 生命周期中对其进行管理 AWS 区域。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 是一项完全托管式构建服务，可编译源代码、运行单元测试和生成部署就绪的构件。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 是一项版本控制服务，可帮助您私下存储和管理 Git 存储库，而无需管理自己的源代码控制系统。 AWS CodeCommit 现已不再向新客户提供。的现有客户 AWS CodeCommit 可以继续照常使用该服务。有关更多信息，请参阅[如何将 AWS CodeCommit 仓库迁移到其他 Git 提供商](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 可帮助您快速对软件发布过程的不同阶段进行建模和配置，并自动执行持续发布软件变更所需步骤。
+ [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) 是一项安全、可扩展且可靠的托管容器映像注册表服务。
+ [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)是一项快速且可扩展的容器管理服务，可帮助运行、停止和管理集群上的容器。
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) 可帮助您创建和控制加密密钥以帮助保护您的数据。
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)帮助您集中管理已获批准的 IT 服务目录。 AWS最终用户可在遵循组织设定约束的情况下快速部署他们所需已获得批准的 IT 服务。
+ [Amazon Simple Storage Service（Amazon S3）](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)是一项基于云的对象存储服务，可帮助您存储、保护和检索任意数量的数据。

**其他工具**
+ [CloudFormation Linter（cfn-lint）是一款根据](https://github.com/aws-cloudformation/cfn-lint)[资源规范检查 CloudFormation YAML 或 JSON 模板的 linter。CloudFormation ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-resource-specification.html)它还会执行其他检查，例如检查资源属性的有效值以及是否遵守最佳实践。
+ [cfn-nag](https://github.com/stelligent/cfn_nag) 是一个开源工具，它通过搜索模式来识别 CloudFormation 模板中的潜在安全问题。
+ [Docker](https://www.docker.com/) 是一组平台即服务（PaaS）产品，它们使用操作系统级别的虚拟化技术在容器中交付软件。该模式使用 Docker 在本地构建和测试容器映像。
+ [Git](https://git-scm.com/docs) 是开源分布式版本控制系统。

**代码存储库**

此模式的代码可在 d GitHub [ynamic\_hotfix\_](https://github.com/aws-samples/dynamic_hotfix_codepipeline) codepipeline 存储库中找到。

## 最佳实践
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-best-practices"></a>

查看并调整您环境中的 IAM 角色和服务控制策略（SCP），以确保它们适当地限制访问。这对于防止任何可能覆盖此模式中包含的安全措施的行为至关重要。遵循最低权限原则，并授予执行任务所需的最低权限。有关详情，请参阅 IAM 文档中的[授予最低权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)和[安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。

## 操作说明
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-epics"></a>

### 设置工作环境
<a name="set-up-the-work-environment"></a>


| Task | 说明 | 所需技能 | 
| --- | --- | --- | 
| 克隆存储库。 | 要将示例[存储库](https://github.com/aws-samples/dynamic_hotfix_codepipeline)克隆到工作地点的新目录中，请运行以下命令：<pre>git clone git@github.com:aws-samples/dynamic_hotfix_codepipeline.git</pre> | AWS DevOps | 
| 导出用于 CloudFormation 堆栈部署的环境变量。 | 定义以下环境变量，这些变量将在此模式的后面用作 CloudFormation 堆栈的输入。[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)<pre>export BucketStartName=<BucketName></pre>[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)<pre>export ProdAccount=<prodaccountnumber><br />export StageAccount=<stage/preprodaccountnumber><br />export QAAccount=<qaccountnumber><br />export ToolsAccount=<toolsaccountnumber><br />export DepRegion=<region></pre> | AWS DevOps | 

### 设置中必需的先决条件 AWS 账户
<a name="set-up-prerequisites-required-in-aws-accounts"></a>


| Task | 说明 | 所需技能 | 
| --- | --- | --- | 
| 在工具账户 CI/CD 中创建所需的资源。 | 要在工具账户中部署 CloudFormation 堆栈，请使用以下命令。（如果您不使用 QA 账户进行设置，请删除该 `QAAccount` 参数。）<pre>#InToolsAccount<br />aws cloudformation deploy \<br />    --template-file pre-requisites/pre-reqs.yaml \<br />    --stack-name prereqs \<br />    --parameter-overrides BucketStartName=${BucketStartName} \<br />    ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \<br />    StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \<br />    QAAccount=${QAAccount} \<br />    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}</pre><br />记下 CodeCommit 存储库和 Amazon ECR 从前面的堆栈中创建的资源。在接下来的步骤中，设置管道的 `main` 分支需要用到这些参数。 | AWS DevOps | 
| 在工作负载帐户 CI/CD 中创建所需的资源。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | 
| 更新 S3 构件存储桶策略以允许工作负载账户访问。 | 要更新工具帐户中的 CloudFormation 堆栈先决条件，请使用以下命令为阶段和生产工作负载帐户添加所有必需的权限。（如果您不使用该 `QAAccount` 参数进行设置，请将其删除。）<pre>#InToolsAccount<br />aws cloudformation deploy \<br />    --template-file pre-requisites/pre-reqs.yaml \<br />    --stack-name prereqs \<br />    --parameter-overrides BucketStartName=${BucketStartName} \<br />    ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \<br />    StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \<br />    QAAccount=${QAAccount} PutPolicy=true \<br />    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}</pre> | AWS DevOps | 

### 在工具账户中设置 Lambda 函数和 Service Catalog 资源
<a name="set-up-lam-function-and-sc-resources-in-tools-account"></a>


| Task | 说明 | 所需技能 | 
| --- | --- | --- | 
| 设置 Service Catalog 产品组合和产品。 | 要设置 Service Catalog 产品组合和产品，请执行以下操作：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | 
| 设置 Lambda 函数。 | 此解决方案使用以下 Lambda 函数来管理修补程序工作流：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)<br />要使 Lambda 函数能够在通过关联 EventBridge 规则创建或删除`hotfix `分支时预置和终止 Service Catalog 产品，请使用以下步骤：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | 

### 为主分支创建管道并在工作负载账户中部署应用程序
<a name="create-pipeline-for-main-branch-and-deploy-application-in-workload-accounts"></a>


| Task | 说明 | 所需技能 | 
| --- | --- | --- | 
| 为 `main` 分支设置管道。 | 要为主分支设置管道，请在工具账户中运行以下命令。将 `MainProductId` 和 `MainProductArtifactId` 的参数替换为 `servicecatalogsetup` 堆栈输出中的值。<pre>#InToolsAccount<br />aws servicecatalog provision-product \<br />    --product-id <MainProductId> \<br />    --provisioning-artifact-id <MainProductArtifactId> \<br />    --provisioned-product-name "${ApplicationName}-main-pipeline" \<br />    --provisioning-parameters Key=CodeCommitRepoName,Value="${ApplicationName}-repository" Key=ECRRepository,Value="${ApplicationName}-app" \<br />    --region=${DepRegion}</pre> | AWS DevOps | 
| 使用 `main` 分支部署应用程序。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | 

### 为 hotfix-\* 分支创建管道并部署此修补程序
<a name="create-the-pipeline-for-a-hotfix--branch-and-deploy-the-hotfix"></a>


| Task | 说明 | 所需技能 | 
| --- | --- | --- | 
| 创建 `hotfix-*` 分支并提交更改。 | 要为 `hotfix-*` 分支创建管道并将修补程序部署到工作负载账户，请执行以下操作：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | 
| 删除 `hotfix-check1` 分支。 | 要删除之前创建的 `hotfix-check1` 分支，请执行以下操作：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | 

### 清理 资源
<a name="clean-up-resources"></a>


| Task | 说明 | 所需技能 | 
| --- | --- | --- | 
| 清理部署的资源。 | 要清理之前部署的先决条件，请执行以下操作：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)<pre>##In Tools Account##<br />aws cloudformation delete-stack --stack-name servicecatalogsetup --region ${DepRegion}<br />aws cloudformation delete-stack --stack-name prlambdasetup --region ${DepRegion}<br />aws cloudformation delete-stack --stack-name prereqs --region ${DepRegion}</pre><pre>##In Workload Accounts##<br />aws cloudformation delete-stack --stack-name inframainstack --region ${DepRegion}</pre><br />有关更多信息，请参阅 Service Catalog 文档中的[删除预调配产品](https://docs.aws.amazon.com/servicecatalog/latest/userguide/enduser-delete.html)。 | AWS DevOps | 

## 问题排查
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-troubleshooting"></a>


| 问题 | 解决方案 | 
| --- | --- | 
| 您提交到 CodeCommit 存储库的更改尚未部署。 | 检查 CodeBuild 日志，查看 Docker 构建操作中是否存在错误。有关详情，请参阅 [CodeBuild 文档](https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html)。 | 
| 未预调配 Service Catalog 产品。 | 查看相关 CloudFormation 堆栈中是否存在失败的事件。有关详情，请参阅 [CloudFormation 文档](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html)。 | 

## 相关资源
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-resources"></a>
+ [基本 Git 命令](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-basic-git.html)
+ [配置 IAM 策略以限制向分支的推送和合并](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-conditional-branch.html#how-to-conditional-branch-create-policy)
+ [Connect 连接到 AWS CodeCommit 存储库](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html)
+ [向用户授予访问权限](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_users.html)
+ [将 Docker 镜像推送到亚马逊 ECR 私有存储库](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)
+ [故障排查 AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html)
+ [什么是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)

## 附加信息
<a name="automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-additional"></a>

此模式专为具有 Gitflow 设置的环境而设计，该设置用于流程中的 CI/CD 开发工作流程。这些管道遵循以下部署周期：从开发开始，依次经过质量保证（QA）、预发布和生产环境。该 CI/CD 设置包括两个 git 分支，它们对环境进行了促销部署，如下所示：
+ `develop` 分支部署到开发环境。
+ `main` 分支部署到 QA、预发布和生产环境。

在这种设置中，在积极开发新功能的同时，要比通常的部署周期更快地应用修补程序或安全补丁是一项挑战。需要专用的流程来处理修补程序或安全请求，从而确保实时环境保持正常运行和安全。

但是，在下面的情况中，您可以使用其他可用选项，而无需专门的部署流程：
+ 该 CI/CD 流程配备了功能和测试等自动化 end-to-end测试，无需手动测试，并可防止部署到生产的延迟。但是，如果自动化测试没有很好地集成到 CI/CD 流程中，那么对开发人员来说，向生产环境推送一个小修复程序可能会变得复杂而繁琐。这是因为 QA 环境中可能有新功能等待批准和签署。修补程序或安全补丁无法以简单的方式同时投入到生产环境。
+ 开发团队不断将新功能部署到生产环境，从而将修补程序或安全补丁集成到每个新功能的计划部署中。换句话说，生产环境的下一次功能更新包括两个组件：增加新功能和包含修补程序或安全补丁。但是，如果部署周期不连续，则 QA 环境中可能已有多个新功能正在等待批准。管理不同的版本并确保重新应用正确的更改会变得复杂且容易出错。

**注意**  
如果您使用的是[版本 2](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipeline-types.html#:~:text=V2%20type%20pipelines%20have%20the%20same%20structure)，并在`hotfix`分支上设置了适当的触发器，则仍然需要一个专门的流程来处理计划外的请求。 AWS CodePipeline 在版本 2 中，您可以为推送或拉取请求设置触发器。执行将排队或立即执行，具体取决于管道的先前状态。但是，通过专用管道，修复程序会立即应用于生产环境，从而确保紧急问题毫不拖延地得到解决。