使用亚马逊 CodeCatalyst 实现 GitFlow

作者： 迈克尔·奥德 | 202 日

亚马逊 CodeCatalyst 是一项统一的软件开发服务，用于在 亚马逊云科技 上构建和交付应用程序。使用CodeCatalyst，您可以实施团队的首选分支策略。无论您是遵循诸如 GitFlow 之类的流行模型 还是采用自己的方法，CodeCatalyst工作流程都允许您设计开发过程并部署到多个环境。

简介

在本系列的上一篇文章《 使用工作流程使用 Amazon CodeCatalyst 构建、测试和部署》中 ，我们讨论了在 CodeCatalyst 中创建持续集成和持续交付 (CI/CD) 管道，以及如何通过使用一个工作流程持续提供高质量更新。我将在这些概念的基础上再接再厉，重点介绍如何使用多个 CodeCatalyst 工作流程来模拟团队的分支策略，从而在代码库中进行协作。

采用标准化流程来管理代码库的更改，可以让开发人员以可预测的方式进行协作，专注于交付软件。一些流行的分支模型包括 GitFlow、GitHub 流程和基于主干的开发。

  • GitF low 旨在通过并行开发和发布来管理大型项目，其中包括多个长期运行的分支。
  • GitHub Flow 是一个基于分支的轻量级工作流程，涉及创建功能分支并将更改合并到主分支中。
  • 基于 Trunk 的开发 侧重于保持主分支始终稳定且可部署。所有更改都直接对主分支进行，并使用自动测试和部署工具识别和修复问题。

在这篇文章中，我将演示如何使用 CodeCatalyst 实现 GitFlow。GitFlow 使用两个永久分支，即 主 分支 和 开发 分支 ，并带有支持分支。支持分支的前缀名称赋予它们所服务的功能——功能、版本和修补程序。我将应用这种策略，将这些分支分支分为 生产 和 集成 ，两者都有自己的 工作流程 和 环境 。 主 分支将部署到 生产环境 ， 开发 分支加上支持分支将部署到 集成 。

Implementing GitFlow with CodeCatalyst
图 1。使用 CodeCatalyst 实现 GitFlow。

完成演练后，你将能够利用这些技术来实现任何流行的模型，甚至是你自己的模型。

先决条件

如果您想继续进行演练，则需要：

  • 拥有 A WS 生成器 ID 用于登录 CodeCatalyst。
  • 属于某个空间并在该空间中为您分配空间管理员角色。 有关更多信息，请参阅在 C odeCatalyst 中 创建空间 、 管理空间成员和 空间管理员 角色。
  • 拥有一个与您的空间关联的 亚马逊云科技 账户，并在该账户中拥有 IAM 角色。有关角色和角色策略的更多信息，请参阅 创建 CodeCatalys t 服务角色。

草率排练

在本演练中，我将使用默认配置的 静态网站 蓝图。CodeCatalyst 蓝图创建了新项目，其中包含入门所需的一切。要亲自尝试一下，请按照在 Amazon CodeC atalyst 中 创建项目中 概述的步骤启动蓝图。

新项目启动后，我将导航到 C I/CD > 环境 。 我看到一个叫 生产 的环境 。该环境是在蓝图创建项目时设置的。我现在将添加我的 集成 环境。为此，我单击环境列表 上方的 “ 创建环境 ”。

Initial environment list with only production.
图 2。仅包含生产环境的初始环境列表。

CodeCatalyst 环境是部署代码并配置为使用 亚马逊云科技 账户连接与您的 亚马逊云科技 账户关联的地方。多个 CodeCatalyst 环境可以与一个 亚马逊云科技 账户相关联，这样您就可以在 CodeCatalyst 中使用与一个 亚马逊云科技 账户关联的用于开发、测试和暂存的环境。

在下一个屏幕中，我输入环境名称作为 集成 ， 为环境类型选择 非生产 ，提供环境的简要描述，然后选择要部署到的 亚马逊云科技 账户的连接。要了解有关连接 亚马逊云科技 账户的更多信息，请查看 亚马逊 CodeC atalyst 中的使用 亚马逊云科技 账户 。我会记下我的连接 名称 和 角色 ，因为我稍后在工作流程中会用到它。输入 集成 环境的所有详细信息后，我单击表单底部的 创建环境 。当我导航回到 C I/CD > 环境时， 我现在会看到这两个环境 都列出了这两个环境。

Environment list with integration and production.
图 3。包含集成和生产的环境列表。

现在我有了 生产 和 集成 环境，我想设置我的工作流程，将我的分支部署到每个单独的环境中。接下来，我导航到 CI/CD > 工作流程 。 就像环境一样，创建的蓝图已经设置了一个名为 onpush BuildTestandDeploy 的工作流程。为了查看工作流程，我选择了 “ 操作 ” 菜单 下的 “ 编辑 ” 。

OnPushBuildTestAndDeploy workflow Actions menu.
图 4。onpushBuildTestand Deploy 工作流程

通过查看工作流程 YAML，我看到 onpushBuildTestandDeploy 工作流程是由 主 分支触发并部署 到生产环境的。 下面我重点介绍了 YAML 中定义每一个的部分。定义 中的 触发器 决定工作流程应何时开始运行以及将代码部署到的 环境 。 

Name: OnPushBuildTestAndDeploy
...
Triggers:
  - Type: PUSH
    Branches:
      - main
...
  Deploy:
...
    Environment:
      Name: production
      Connections:
        - Name: ****
          Role: ****

既然这确认了 生产 工作流程已经完成，我将复制这个 YAML 并用它来创建我的 集成 工作流程。 将整个 onpushBuildTestandDeploy YAML 复制到剪贴板（不仅仅是上面的精彩片段）后，我导航回到 CI/C D > 工作流程，然后单击 “创建工作流程”。 然后在 “ 创建工作流程 ” 对话框窗口中单击 “ 创建 ” 。

Create workflow dialog window.
图 5。创建工作流程对话窗口。

在工作流程 YAML 编辑器中，我通过粘贴剪贴板上的 onpushBuildTestandDe ploy YAML 来替换所有现有内容。我在 YAML 中编辑的第一件事是工作流程的名称。 我通过找到 名为 Nam e 的属性 并将 onpushbuildTestandDeploy 替换为 onIntegrat ionpushbuildTestand

接下来，我想将触发器更改为 开发 分支，并通过前缀匹配支持分支。触发器允许您指定多个分支，并且可以使用正则表达式定义分支名称以匹配多个分支。要进一步探索触发器，请阅读 使用触发器 。 

Triggers:
  - Type: PUSH
    Branches:
      - develop
      - "feature/.*"
      - "release/.*"
      - "hotfix/.*"

更新触发器后，我需要使用我的 集成 环境 更新 环境 属性。我将 “ 名称 ” 和 “ 连接 ” 属性替换为我的 集成 环境的正确值。我使用之前记 下的 集成 环境连接中的 名称 和 角色 。有关工作流中环境的更多详细信息，请查看 使用环境 。 

  Deploy:
...
    Environment:
      Name: integration
      Connections:
        - Name: ****
          Role: ****

在完成 集成 工作流程之前，我已经重点介绍了在 “部署” 操作中使用 $ {workflowSource.BranchNam e}。 该工作流程使用 BranchName 变量来防止不同的分支部署相互覆盖。验证这一点很重要，因为所有集成分支都使用相同的环境。 WorkflowSou rce 操作会自动将 C ommitID 和 Branch Name 输出到工作流程变量。要了解有关工作流程中变量的更多信息，请查看 使用变量 。 

  Deploy:
...	
    Configuration:
      AmplifyBranchName: ${WorkflowSource.BranchName}

我在下面列出了整合 p ushbuildTestandDeploy 工作流程的 完整示例。由于没有自动清理，因此即使在合并和删除分支之后，开发人员也有责任删除其分支创建的资源。

Entire sample integration workflow.
图 6。整个示例集成工作流程。

通过单击 “验证” 验证 工作流程的语法后 ，我单击 “ 提交 ” 。在 “ 提 交” 工作流 模式窗口 中单击 “提 交 ” 以确认此操作。

Commit workflow dialog window.
图 7。提交工作流程对话框窗口。

提交工作流程后，我可以在工作流程列表中立即看到新的 onIntegrationPushbuildTestandDe ploy 工作流程。我看到工作流程显示 “工作 流程处于非活动状态” 。这是意料之中的，因为我正在查看 主 分支，触发器不是从 ma in 调用的 。

现在我已经完成了 GitFlow 的实现细节，我现在要创建永久 开发 分支和功能分支来测试我的 集成 工作流程。 要添加新分支，我进入 代码 > 源存储库 > 静态网站内容 ，在 “更多” 菜单下选择 “ 创建分支 ”。

Source repository Actions menu.
图 8。源存储库操作菜单。

输入 d evelop 作为我的分支名称，从 主 分支创建分支 ，然后单击 “ 创建 ” 。

Create the develop branch from main.
图 9。从 main 创建开发分支。

我现在通过导航回创建分支屏幕来添加功能分支。 这次，我输入 fe ature/gitflow-demo 作为我的分支名称，从 develop 中创建分支，然后单击 “创建” 。

Create a feature branch from develop.
图 10。从 develop 中创建功能分支。

为了确认我已经成功实现了 GitFlow，我需要验证功能分支工作流程是否正在运行。 我返回 C I/CD > 工作流程 ， 从分支下拉列表中选择 功能/gitflow-demo ，然后看到集成工作流程正在运行。

Feature branch running integration workflow.
图 11。功能分支运行集成工作流程。

为了完成对 GitFlow 实现的测试，我需要等待工作流程成功。然后，我通过导航到工作流程并单击最后一个工作流程操作上的 “ 查看应用程序 ” 链接来查看新部署的分支。

最后，既然GitFlow已经实现和测试，我将逐步将功能分支投入生产。 在我对功能分支进行代码更改后，我创建了一个拉取请求，将 功能/gitflow-demo 合并到开发中。 请注意， 本系列 的前一篇文章中 已经介绍了拉取请求 。合并拉取请求时，选择 合并此拉取请求后 删除源分支 ，因为该功能分支不是永久分支。

Deleting the feature branch when merging.
图 12。合并时删除功能分支。

现在我的更改已在 开发 分支中，我创建了一个发布分支。我导航回创建分支屏幕。 这次我输入 release/v1 作为我的分支名称，从 develop 中创建分支 ，然后单击 “创建”。

Create the release branch from main.
图 13。从 main 创建发布分支。

我已经准备好发布到 生产环境 了 ，所以我创建了一个拉取请求，将 release/v1 合并到主版本 中。 发布分支不是永久分支，因此也可以在合并时将其删除。当拉取请求合并到主请求时， onpushBuildTestandDe ploy 工作流程将运行。工作流程完成运行后，我可以验证我的更改是否在 生产 中 。

清理

如果您一直遵循此工作流程，则应删除部署的资源，以免继续产生费用。首先，删除在启动蓝图并配置新环境时关联的 亚马逊云科技 账户中使用 亚马逊云科技 CloudFormation 控制台部署的两个堆栈。这些堆栈的名称将像 St atic-Web-xxxxx 一样。 其次，通过导航到项目 设置并选择 “删除项目”，从 CodeCatalyst 中删除 该项目 。

结论

在这篇文章中，你学习了如何在多个工作流程中使用触发器和环境通过 Amazon CodeCatalyst 实现 GitFlow。通过使用工作流程中的变量，我能够进一步自定义我的部署设计。使用这些概念，您现在可以使用 CodeCatalyst 实现团队的分支策略。 了解有关亚马逊 CodeCatalyst 的更多信息并立即开始吧！

迈克尔·奥德

迈克尔·奥德是来自加利福尼亚州长滩的高级解决方案架构师。作为 亚马逊云科技 的产品加速解决方案架构师，他目前通过使用无服务器、DevOps 和 AI/ML 等实践构建现代应用程序，为 GovTech 和 EdTech 领域的独立软件供应商 (ISV) 提供协助。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。