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

由迈克·斯蒂芬斯 (AWS) 和 Abhilash Vinod () 创作 AWS

摘要

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

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

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

先决条件和限制

先决条件

• Git，已安装。它用作源代码存储库工具。

• draw.io，已安装。此应用程序用于查看和编辑图表。

架构

目标架构

下图可以像 Punnett 方块一样使用（维基百科）。您可以将垂直轴上的分支与水平轴上的 AWS 环境对齐，以确定在每个场景中要执行的操作。这些数字表示工作流程中操作的顺序。此示例将带您从feature分支机构到生产环境中的部署。

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

自动化和扩缩

持续集成和持续交付（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自动部署到亚马逊弹性计算云 (AmazonEC2)、本地实例、 AWS Lambda 函数或亚马逊弹性容器服务 (AmazonECS) 服务。

• AWS CodePipeline帮助您快速建模和配置软件发布的不同阶段，并自动执行持续发布软件更改所需的步骤。

其他工具

• Draw.io 桌面是一款用于制作流程图和图表的应用程序。代码存储库包含 drawio 格式的 drawio 格式的 drawio 模板。

• Figma 是一款专为协作而设计的在线设计工具。代码存储库包含 Figma 的.fig 格式的模板。

代码存储库

此模式下图表的源文件可在 GitHub Git GitHub Flow 分支策略存储库中找到。它包括 draw.io 和 Figma 格式的文件。PNG您可以修改这些图表以支持贵组织的流程。

最佳实践

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

操作说明

查看 GitHub Flow 工作流程

任务	描述	所需技能
查看标准 GitHub 流程流程。	在沙盒环境中，开发人员从feature分支创建分main支并使用命名模式feature/<ticket>_<initials>_<short description>。 开发者向feature分支添加一个或多个提交，每个提交都代表一个离散的更改或改进。 开发者打开合并请求 (MR)，将更改合并到main分支中。这将启动审核流程。 在审查过程中，开发人员会讨论代码变更并提供反馈。目标是确保变更的高质量并符合项目的标准。 开发者创建合并请求后，将启动自动构建流程，并将feature分支中的更改部署到开发环境中。 自动测试可验证合并请求中封装的更改的完整性和质量。完成合并请求需要成功构建、成功部署和成功测试。 审阅过程完成后，更改将合并到分main支中。 批准者手动批准将发布构件部署到测试环境。 批准者手动批准将发布构件部署到暂存环境。 批准者手动批准将发布构件部署到生产环境。	DevOps 工程师
查看错误修复 GitHub 流程流程。	开发人员从该bugfix分支创建一个main分支并使用命名模式bugfix/<ticket number>_<developer initials>_<descriptor>。 开发者修复了问题，提交了修复并构建了bugfix分支。 开发者打开合并请求，要求将bugfix分支合并到分main支中。这将启动审核流程。 在审查过程中，开发人员会讨论代码变更并提供反馈。 审核完成并获得批准后，开发者将完成分支合并到bugfix分main支的请求。 批准者手动批准将发布构件部署到更高的环境。	DevOps 工程师
查看修补程序 GitHub 流程流程。	GitHub Flow 旨在实现持续交付，在这种交付中，可以频繁可靠地将代码更改部署到更高的环境中。关键是每个feature分支都可以随时部署。 Hotfix类似于feature或bugfix分支的分支可以遵循与其他分支相同的过程。但是，考虑到其紧迫性，修补程序通常具有更高的优先级。根据团队的政策和情况的即时性，可以加快流程中的某些步骤。例如，修补程序的代码审查可能会被快速跟踪。因此，尽管修补程序过程与功能或错误修复过程相似，但由于围绕修补程序的紧迫性，可能需要修改程序遵守情况。必须制定有关管理修补程序的指导方针，以确保高效、安全地处理修补程序。	DevOps 工程师

故障排除

事务	解决方案
分支冲突	GitHub Flow 模型可能出现的一个常见问题是，需要在生产环境中进行修补程序，但需要在修改相同资源的featurebugfix、或hotfix分支中进行相应的更改。我们建议您经常将来自较低分支的更改合并main到较低分支中，以避免在合并到时发生重大冲突main。
团队成熟度	GitHub Flow 鼓励每天部署到更高的环境，采用真正的持续集成和持续交付 (CI/CD)。团队必须具备工程成熟度，才能构建功能并为其创建自动化测试。在批准变更之前，团队必须对合并请求进行详尽的审查。这培养了一种强大的工程文化，促进了开发过程的质量、问责制和效率。

相关资源

本指南不包括针对 Git 的培训；但是，如果您需要此培训，互联网上有许多高质量的资源可供选择。我们建议您从 Git 文档网站开始。

以下资源可以帮助您完成 GitHub Flow 分支之 AWS Cloud旅。

AWS DevOps 指导

• AWS DevOps 指南

• AWS 部署管道参考架构

• 什么是 DevOps？

• DevOps resources

GitHub 流量指导

• GitHub Flow 快速入门教程 () GitHub

• 为什么 GitHub Flow？

其他资源

• 十二因子应用程序方法论 (12factor.net)