为多账户环境实施 Gitflow 分支策略 DevOps

迈克·斯蒂芬斯、斯蒂芬 DiCato、Abhilash Vinod 和 Amazon Web Services 的 Tim Wondergem

Summary

管理源代码存储库时，不同的分支策略会影响开发团队使用的软件开发和发布流程。常见分支策略的示例包括 Trunk、Gitflow 和 Flow。 GitHub 这些策略使用不同的分支，并且在每种环境中执行的活动也各不相同。正在实施 DevOps 流程的组织将受益于可视化指南，以帮助他们了解这些分支策略之间的区别。在组织中使用此视觉对象可以帮助开发团队协调工作并遵循组织标准。此模式提供了该视觉对象，并描述了在组织中实施 Gitflow 分支策略的过程。

这种模式是关于为具有多个 AWS 账户分支机构的组织选择和实施 DevOps 分支策略的文档系列的一部分。该系列旨在帮助您从一开始就应用正确的策略和最佳实践，以简化您的云体验。Gitflow 只是您的组织可以使用的一种潜在分支策略。本文档系列还涵盖了 Tr unk 和 GitHub Flow 分支模型。如果你还没有这样做，我们建议你先查看为多账户 DevOps 环境选择 Git 分支策略，然后再按此模式实施指南。请务必谨慎选择适合组织的分支策略。

本指南提供了图表，其中显示了组织如何实施 Gitflow 策略。建议您查看《Well-Ar DevOps chitec AWS ted 指南》，以查看最佳实践。此模式包括 DevOps 流程中每个步骤的推荐任务、步骤和限制。

先决条件和限制

先决条件

Git，已安装。这可用作源代码存储库工具。
Draw.io，已安装。此应用程序可用于查看和编辑图表。
（可选）Gitflow 插件，已安装。

架构

目标架构

下图的使用方法与旁氏表类似（维基百科）。您可以将垂直轴上的分支与水平轴上的 AWS 环境对齐，以确定在每个场景中要执行的操作。这些数字表示工作流中各项操作的顺序。此示例可引导您了解从特征分支到在生产环境中部署的整个过程。

有关 Gitflow 方法中的 AWS 账户、环境和分支的更多信息，请参阅为多账户环境选择 Git 分支策略。 DevOps

自动化和扩展

持续集成和持续交付（CI/CD) is the process of automating the software release lifecycle. It automates much or all of the manual processes traditionally required to get new code from an initial commit into production. A CI/CD pipeline encompasses the sandbox, development, testing, staging, and production environments. In each environment, the CI/CD pipeline provisions any infrastructure that is needed to deploy or test the code. By using CI/CD, development teams can make changes to code that are then automatically tested and deployed. CI/CD管道）还通过强制执行一致性、标准、最佳实践以及功能接受和部署的最低接受程度，为开发团队提供管理和护栏。有关更多信息，请参阅上的 “练习持续集成和持续交付” AWS。

AWS 提供了一套旨在帮助您构建 CI/CD 管道的开发人员服务。例如，AWS CodePipeline是一项完全托管的持续交付服务，可帮助您实现发布管道的自动化，从而实现快速可靠的应用程序和基础设施更新。 AWS CodeBuild编译源代码、运行测试和生成 ready-to-deploy软件包。有关更多信息，请参阅上的开发者工具 AWS。

工具

AWS 服务和工具

AWS 提供了一套开发者服务，你可以用它们来实现这种模式：

AWS CodeArtifact 是一项高度可扩展的托管式构件存储库服务，有助于您存储和共享用于应用程序开发的软件包。
AWS CodeBuild 是一项完全托管式构建服务，可编译源代码、运行单元测试和生成部署就绪的构件。
AWS CodeDeploy自动部署到亚马逊弹性计算云 (Amazon EC2)、本地实例、 AWS Lambda 函数或亚马逊弹性容器服务 (Amazon ECS) 服务。
AWS CodePipeline 可帮助您快速对软件发布过程的不同阶段进行建模和配置，并自动执行持续发布软件变更所需步骤。

其他工具

Draw.io 桌面是用于制作流程图和图表的应用程序。代码存储库包含 Draw.io 的 .drawio 格式模板。
Figma 是一款专为协作而打造的在线设计工具。代码存储库包含 Figma 的 .fig 格式模板。
（可选）Gitflow 插件是 Git 扩展的集合，它们可为 Gitflow 分支模型提供高级存储库操作。

代码存储库

此模式下图表的源文件可在 GitFlow存储库的 GitHub Git 分支策略中找到。其包括采用 PNG、draw.io 和 Figma 格式的文件。您可以修改这些图表，以为组织的流程提供支持。

最佳实践

遵循 Well-Architect AWS e DevOps d 指南和为多账户环境选择 Git 分支策略中的最佳实践和建议。 DevOps 这些最佳实践可以帮助您有效地实施基于 Gitflow 的开发、促进协作、提高代码质量以及简化开发流程。

操作说明

Task	说明	所需技能
查看标准的 Gitflow 流程。	在沙盒环境中，开发人员从 `develop` 分支创建 `feature` 分支并使用命名模式 `feature/<ticket>_<initials>_<short description>`。开发人员开发代码，并以迭代方式将代码部署到沙盒环境中，进而完成票证。注意开发人员可以选择创建一个 `sandbox` 分支，在沙盒环境中运行自动构建或部署管道。开发人员使用压缩合并创建从 `feature` 分支到 `develop` 分支的合并请求。持续集成和持续交付（CI/CD）管道可自动构建和部署 `develop` 分支并将其发布到开发环境。（可选）在继续发布活动之前，开发人员会将其他 `feature` 分支集成到开发分支中。当您准备好在 `develop` 分支中发布功能时，开发人员会从 `develop` 分支创建一个名为 `release/v<number>` 的 `release` 分支。开发人员构建发布分支，而该分支会发布构件，以供其他环境重复使用。审批者会手动批准将发布构件部署到测试环境。审批者会手动批准将发布构件部署到暂存环境。审批者会手动批准将发布构件部署到生产环境。开发人员将 `release` 分支合并到 `main` 分支中。理想情况下，开发人员会使用自动化脚本来执行快进式合并。请勿使用压缩合并。开发人员将 `release` 分支合并到 `develop` 分支中。理想情况下，开发人员会使用自动化脚本来执行快进式合并。请勿使用压缩合并。	DevOps 工程师
查看修补程序 Gitflow 流程。	开发人员从 `main` 分支创建 `hotfix` 分支并使用命名模式 `hotfix/<ticket>_<initials>_<short description>`。开发人员从 `main` 分支创建 `release` 分支并将其命名为 `release/v<number>`。开发人员修复了问题，提交了修复并构建了 `hotfix` 分支。开发人员使用压缩合并创建从 `hotfix` 分支到 `release/v<number>` 分支的合并请求。开发人员构建 `release` 分支，而该分支会发布构件，以供其他环境重复使用。审批者会手动批准将发布构件部署到测试环境。审批者会手动批准将发布构件部署到暂存环境。审批者会手动批准将发布构件部署到生产环境。开发人员将 `release` 分支合并到 `main` 分支中。理想情况下，开发人员会使用自动化脚本来执行快进式合并。请勿使用压缩合并。开发人员将 `release` 分支合并到 `develop` 分支中。理想情况下，开发人员会使用自动化脚本来执行快进式合并。请勿使用压缩合并。如果检测到冲突，开发人员会收到提醒，并通过合并请求来解决冲突。	DevOps 工程师
查看错误修复 Gitflow 流程。	开发人员从当前的 `release/v<number>` 分支创建 `bugfix` 分支并使用命名模式 `bugfix/<ticket number>_<developer initials>_<descriptor>`。开发人员修复了问题，提交了修复并构建了 `bugfix` 分支。开发人员使用压缩合并创建从 `bugfix` 分支到 `release/v<number>` 分支的合并请求。开发人员构建 `release` 分支，而该分支会发布构件，以供其他环境重复使用。审批者会手动批准将发布构件部署到测试环境。审批者会手动批准将发布构件部署到暂存环境。审批者会手动批准将发布构件部署到生产环境。开发人员将 `release` 分支合并到 `main` 分支中。理想情况下，开发人员会使用自动化脚本来执行快进式合并。请勿使用压缩合并。开发人员将 `release` 分支合并到 `develop` 分支中。理想情况下，开发人员会使用自动化脚本来执行快进式合并。请勿使用压缩合并。如果检测到冲突，开发人员会收到提醒，并通过合并请求来解决冲突。	DevOps 工程师

问题排查

问题	解决方案
分支冲突	Gitflow 模型可能出现的一个常见问题是，生产环境需要修补程序，但较低级别的环境中也需要进行相应更改，因为另一个分支中同样存在要修改的资源。我们建议您一次仅激活一个发布分支。如果您一次有多个分支处于活动状态，则环境中的更改可能会发生冲突，并且您可能无法将分支推进到生产中。
合并	应尽快将版本合并回主分支并进行开发，以便将工作整合回主分支。
压缩合并	只有在从 `feature` 分支合并到 `develop` 分支时才会使用压缩合并。在较高的分支中使用压缩合并，可能会导致在向较低级别分支合并更改时遇到困难。