git - 用于持续交付系统的多个环境的 Github 工作流

Question

如何使用 GitHub for Azure DevOps CI/CD 从一个分支到另一个分支的部分合并？

我对 Github 和 Azure DevOps 真的很陌生。我刚刚开始使用 Azure DevOps 学习 CI/CD，并使用 GitHub 作为项目源构建了一些管道。

你能帮我弄清楚我们应该如何为 CI 管理它的工作流程吗？

我有两种环境——一种是开发环境，另一种是现场环境。每个都有自己的分支，例如用于开发环境的实时和开发主控。两名开发人员参与进行更改，例如功能 A 和功能 B。因此，在完成工作后，他们提交并将更改合并到使用 CI/CD 管道自动部署的开发分支。

在开发环境中，测试人员测试了代码，发现功能 B 没有按应有的方式工作。并对特征 A 执行 OK。

现在我们只想将与 Feature A 相关的代码部署到 master 分支。这应该是什么工作流程？我们如何合并到 master 分支？

PS：每次提交的 CI 触发发生在任何分支上。提交 ID 与 Azure 板中的工作 ID 相关联。

标签： gitgithubazure-devops

Answer 1

微软关于分支策略的文档非常值得一读，重点是让事情尽可能简单。

如果您使用多阶段管道，其中构建 (CI) 和发布 (CD) 阶段在 yaml 代码中定义为一个管道，那么这鼓励您从一个分支构建和部署代码。

如果真的是 2 个开发人员，同时只有 2 个功能正在开发/正在开发，我会说开发分支是矫枉过正，只有主分支和特性分支就足够了。这个想法是在功能 B 合并之前，功能 A 被合并到 master 并一直通过您的管道到您的实时环境。希望在极少数情况下 master 中断然后它是“停止生产线”并且每个人都在合并任何进一步的功能之前修复 master。

如果您对可能破坏 master 感到不安，并且提高不这样做的信心的唯一方法是对环境进行物理部署，您可能会研究应用程序架构，以使基于功能分支（例如容器化（AKS）或无服务器（Azure Functions））和/或引入在构建时运行的集成测试套件。

大多数管道将相同的构建工件从一个环境推送到下一个环境，以最大限度地降低风险，这在 .net 应用程序（DLL 包等）中尤其如此。您描述的场景中的问题是，如果您选择功能 A 的提交，然后构建它，您将把应用程序的一个新的未经测试的版本推向生产。您不知道您是否在挑选樱桃时犯了错误，或者更糟糕的是，功能 B 中的内容允许功能 A 工作。最简单的解决方案是通过管道更频繁地推动较小的更改直至生产（持续交付）。

祝项目好运！