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

【问题标题】：Github workflow for multiple environments for continuous delivery system用于持续交付系统的多个环境的 Github 工作流
【发布时间】：2020-05-09 12:54:43
【问题描述】：

如何使用 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 相关联。

【问题讨论】：

特征A和特征B是两个不同的分支吗？
没有功能 A 和功能 B 是一项将完成任务的工作，例如功能 A 可能创建一个页面，而功能 B 创建另一个页面。当工作完成时，它们最终将与主分支合并。

标签： git github azure-devops

【解决方案1】：

Microsoft 关于branching strategy 的文档非常值得一读，重点是让事情尽可能简单。

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

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

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

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

祝项目好运！

【讨论】：

实际上我面临的主要问题是如何将代码与不同的开发人员隔离开来，因为他们将来可能会更多。早些时候，每当 Qa 团队通过任何工作项时，我们都会从该故事或工作项中获取变更集，并将它们合并到暂存分支。但是对于 github，如果我做同样的事情，例如使用提交 ID 并执行这些提交，我不完全确定该方法是否有效。我也看到了 github 的 cherry pick 命令，但不确定这是否正确。或者开发人员应该在每次提交后进行拉取，然后我将使用这些拉取来合并它？
嗨@prashant，我已经更新了我的答案，说明樱桃采摘会带来风险的原因。我想说的是提交集的拉取请求，无论是完整的功能还是易于查看的不会影响应用程序运行的代码段都是要走的路。单独推动每个更改可能听起来会减慢您的速度，但是专注于尽可能多地自动化（部署和测试）将其投入生产可以解决这个问题，并且根据经验，在推动批量时会权衡准备和解决问题所花费的时间一次不同的变化。
我开始明白这一点。如果我专注于功能而不是单个任务，那么做事会更容易。因此，如果功能 A 需要创建一个登录页面，而功能 B 需要创建一个注册页面。我将等待这两项任务完成并从 QA 获得这两个功能的签字，然后将其推送到另一个环境。这样两个故事都可以先得到测试，并且在转移到另一个环境之前也可以测试影响。
还有你的评论如果我要推送小的更改，它只需要从分支合并，而不是通过樱桃采摘或拉取请求。所以工作流程就像如果开发人员都对开发进行了提交，并且功能 A 被 QA 通过但功能 B 没有通过，那么我们可以要求开发人员 B（负责功能 B）通过使用如果它影响当前构建并将特性 A 代码从开发人员分支移动到主分支，则标记或撤消其更改？
非常感谢。你的讨论对我帮助很大。我会标记为已解决??