敏捷开发中的 CI/CD 和代码审查策略的简单分支策略
0/5 (0投票)
这里是敏捷开发中 CI/CD 和代码审查策略的简单分支策略
代码审查是 DevOps 的一个重要环节，可以在代码上线生产环境之前发现任何错误。在持续集成/持续交付 (CI/CD) 模型中，代码审查尤为重要。存在一些工具可以在源代码层面强制执行代码审查策略。其理念是，任何代码更改都必须先经过审查，然后才能合并到主分支，前提是主分支只包含经过适当审查的代码，以确保质量。本文假设使用 GIT 进行源代码管理，并使用 Team Foundation Server (TFS) 或 Azure DevOps 进行构建/发布和 CI/CD。
作为一名开发人员，在代码被审查之前，通常希望对其进行测试。在大多数情况下，构建和发布管道会配置为监听主分支的变化。在这种情况下，代码审查策略可能会给开发人员带来负担，因为它要求审查可能无法正确工作的代码。此外，开发人员现在需要在开发环境中测试代码之前等待代码审查。如果正在开发的系统无法在本地机器上进行测试，这一点就更加重要了。这也有可能减缓开发活动和冲刺速度，这与敏捷的理念背道而驰。这可能会导致开发人员和审查人员都感到沮丧。通过创建一个工作流程，让开发人员能够在请求代码审查之前，在开发环境中创建、构建、部署和测试代码，就可以避免这些问题。
可以通过改进分支和合并策略以及创建两个构建/发布管道来处理此工作流。为简单起见，我们将这些管道称为 master 和 dev（例如，dev 用于开发）。master 管道由 master 分支的变化触发，而 dev 管道由 dev 分支的变化触发。开发人员可以从 master 创建一个 dev 分支，进行更改，使用 dev 管道进行构建和部署（很可能是在开发服务器上），进行必要的测试，然后创建一个合并到 master 分支的拉取请求（Pull Request），之后再进行审查。从这一点开始，master 管道启动，更改将反映在所有需要的环境中，如开发、演示、UAT 或生产。
通过上述工作流，代码审查策略仍然在 master 分支上强制执行，开发人员可以在提交更改进行审查并最终合并到 master 分支之前，在代码和测试中进行持续的更改。
最少，我们将考虑三种类型的分支，即 master、dev 和 feature，下面将简要描述它们。
- Master 分支
- 主分支
- 始终需要代码审查
- 必须用于构建/发布到生产环境
- 此分支视为永久分支
- 存在针对所有环境的构建和发布定义，并启用了 CI
- Dev 分支
- 辅助分支
- 理想情况下，从 Master 创建
- 可以强制使用 Master
- 不需要代码审查
- 不得用于构建/发布到生产环境
- 此分支视为临时分支。此分支中的内容可能会被清除。
- 存在针对此分支的构建和发布定义，因此已为此分支启用 CI 以部署到开发环境。对于其他环境，此分支没有自动发布。
- 此分支也可用于快速热修复。
- 请注意，如果 dev 合并到 master 导致分支被删除（取决于代码审查请求），则从 master 创建 dev 分支并将其推送到远程就足够了。
- 其他分支（根据需要）
- Feature 分支、需要用于 PBI（产品待办事项项或问题）的分支等。
- 任何人都可以创建，并且可以合并到 master 或 dev 分支
- 理想情况下，从 Master 创建（但也可以从 Dev 创建）
- 编码完成后，可以推送到 Dev 分支以在开发环境中构建/发布
- 编码完成后，必须创建一个拉取请求以合并到 master 分支
- 这些分支在远程是临时的。但你可以在本地保留它们。因此，其性质是半永久的。
- 通过拉取请求，当此分支合并到 master 时，很可能该分支将从远程删除。
场景/用例/流程
下面描述了一些与开发工作相关的场景
处理 PBI
- 从 Master 创建一个分支。对其进行适当命名，使用 pbi 或 feature 或特定关键字，以便轻松识别。
- 进行必要的代码更改。
- 很可能存在 dev 分支。如果存储库中不存在 dev 分支，请创建一个 dev 分支。如果 dev 分支没有构建和发布定义，请也创建它们。
- 将你的分支合并到 Dev（这将触发 Dev 的构建/发布）。
- 如果一切正常，请创建一个针对你的分支的拉取请求。
处理 PBI 但 PBI 被推迟到未来
- 创建了一个分支并将代码合并到 Dev。PBI 已暂时推迟。我需要另一个 Dev 分支。
- 保留 feature 分支。Dev 将使用 master 分支重置。在 dev 中所做的更改将丢失。
- 可以进行“选择性提交”（Cherry-Picking）来恢复一些更改并将其带入当前代码
在 Dev 分支上工作，但需要删除所有新更改
- 选择 dev 分支。指向 master 分支，并将 dev 分支重置到 master 分支上的选定点。
- 如果需要，将本地更改保留到单独的分支。
在 Dev 分支上工作，但 Dev 分支没有构建或发布管道
- 克隆构建定义。将定义重命名为
*-Dev。在存储库中，选择 'dev' 分支。在发布中执行相同的操作。确保自动触发仅限于 'dev' 环境。
上述工作流可行，但有一些假设。将 master 合并到 dev 是安全的（如果开发人员的代码丢失，他们可以随时从 feature 分支再次合并代码到 dev）。因此，所有开发人员都应了解这种可能性，以免产生混淆。但是，为了使流程更顺畅，在日常站会（daily scrum）中进行讨论会是个好主意。在大多数情况下，dev 分支不需要如此频繁地重置，但最好也让 dev 分支包含最新的代码，以避免使用旧版本代码，并避免将来出现合并冲突。
如果 master 无法与 Dev 合并，则强制合并（这将清除冲突并将 Dev 变成 Master 的副本）。通过强制合并，你可以避免手动纠正可能不需要的错误。如果需要，可以从 feature 分支重新应用 dev 中的更改。
Git Extension（一个比 Visual Studio 中的 Git 工具提供更好体验的工具）可用于在实施分支策略时创建、合并、重置和选择性提交。它是免费的，可在 https://git-extensions-documentation.readthedocs.io/en/latest/git_extensions.html 获取。