使用GitHub流程进行开发和生产环境搭建

Question

在工作中，我们现在使用GitHub以及GitHub流程。我理解的GitHub流程是有一个主分支和特性分支，与git流程不同的是没有develop分支。

这在我们完成的项目上运行得非常好，并简化了事情。

然而，对于我们的产品，我们有一个开发环境和一个生产环境。对于生产环境，我们使用master分支，但对于开发环境，我们不确定应该如何处理？

我能想到的唯一想法是：

1. 当一个分支合并到主分支时，使用GitHub操作重新部署master。
2. 当另一个分支被推送时，设置一个GitHub操作，使除了master以外的任何其他分支都部署到此环境。

目前，对于需要开发环境的项目，我们基本上使用git flow（特性→develop→master）。

您认为我的想法是否明智？如果不是，您会推荐什么呢？

编辑：

只是为了澄清，我正在询问使用GitHub流程实现开发的最佳方法，而不是使用git流程。

- Nathan Sainsbury

Answer 1

根据我的经验，使用多个环境的GitHub Flow 的工作方式如下。将代码合并到主分支并不会自动部署到生产环境。相反，合并代码到主分支会创建一个构建构件，可以使用 ChatOps 工具在各个环境之间进行推广。

例如，将代码推送到master会创建一个构建构件，命名为类似于my-service-47cbd6c的内容，它是服务名称和短提交哈希的组合。然后将其推送到某种构件存储库中。然后，可以使用 ChatOps 风格的斜杠命令等工具将构件部署到各种环境中。例如，此工具还可以检查以确保不跳过测试环境。最后，将构件推广到生产环境。

因此，针对您在 GitHub Actions 中的使用情况，我建议如下操作：

1. 将代码推送到 master，创建构建构件并自动将其部署到开发环境。
2. 在开发环境中进行测试
3. 通过使用斜杠命令将构件部署到生产环境来推广构件。可以使用该工具slash-command-dispatch来帮助您完成。

- peterevans

---

谢谢！是的，这正是我在寻找的，这种观点很有趣，我会反馈回去。 - Nathan Sainsbury

@peterevans 免责声明-我从未使用过GitHub Flow，主要使用Git Flow或类似工具。但是大多数关于GitHub流程的来源都说，在合并到主干之前应该先进行生产部署和测试。例如https://dev59.com/WVkS5IYBdhLWcg3wY19z#47016500或https://guides.github.com/introduction/flow/。在您的流程中，只有在推送到“主干”后才开始测试。 - VB_

@VB_ 我只有在相当大的组织中有经验，在将代码合并到主分支后进行部署是常规操作。允许将功能分支部署到生产环境听起来有些危险，除非它得到了仔细的管理。不过，我会说，不要觉得你必须遵循“规则”。多试验一下，做适合你和你的团队的事情。 - peterevans

Answer 2

您可以考虑使用环境的概念（如此处所示）。

最近（2021年2月），您可以：

## 限制可部署到环境的分支

您现在可以使用环境保护规则来限制可以将哪些分支部署到环境中。

当作业尝试使用已配置部署分支进行环境部署时，Actions会检查github.ref的值与配置是否匹配，如果不匹配，则作业将失败并停止运行。

部署分支规则可以配置为允许：

• 所有分支 - 仓库中的任何分支都可以部署
• 受保护的分支 - 仅限具有保护规则的分支
• 选定的分支 - 匹配一组名称模式的分支

这意味着您可以定义一个部署到开发环境的作业，并且该作业只有在从给定分支（master在您的情况下）推送的提交触发时才能运行。

- VonC

Answer 3

对于面临相同问题或想要远离gitflow简化其流程的任何人，我建议您查看这篇文章。虽然它没有明确讨论Github流，但实际上提供了一种解决方案。

纯粹主义者可能认为这不是严格的Gitflow，但在我看来，这是一个简单的调整，使得部署和CI/CD策略在git中更加明确。我更喜欢采用这种方法，而不是向工具添加一些神奇的东西，这可能会使开发人员更难以遵循和理解流程。

我认为Gitflow介绍也写得非常务实：

不同的团队可能有不同的部署策略。对于某些团队，最好部署到专门配置的测试环境。对于其他人来说，直接部署到生产环境可能是更好的选择...

文章中的图表很好地总结了这一点： 因此，这里的Master == Gitflow main，有用的补充是临时发布分支，从中您可以部署到其他环境，如开发。值得考虑的是，您选择将这个临时分支称为什么，在上面被认为是一个发布，在您的过程中可能是一个测试分支等。

您可以保留压缩和标记，工具在团队之间会有所变化。同样，您可能会关心实际版本号。

这与VonC的答案并没有太大的区别，不同之处在于流程更加严格定义，并且更倾向于让多个开发人员合并到单个分支中，并按顺序应用修复程序以准备好新版本供生产使用。也许您可以通过命名约定来配置此临时分支的部署，就像他的答案一样。

- Matt

Answer 4

我实现这个流程的方式是使用PR。我用Azure DevOps实现了它，但我认为同样的效果也可以通过GitHub Actions实现。

当你有一个分支需要测试并最终合并到主分支并发布到生产环境时，你可以从该分支创建一个PR到主分支。PR将触发一个流水线，运行你的构建、静态分析和测试。如果通过了，PR将被部署到一个测试环境，进一步进行自动化和手动测试。其他开发人员可以审查和批准该PR，如果需要，QA也可以在手动测试后进行批准。你可以配置GitHub PR规则来强制执行批准。一旦批准，你就可以将PR合并到主分支。

主分支中发生的事情与上述工作流无关，但很可能会触发一个新的流水线，构建一个发布候选版本，并运行整个路径到生产环境（带或不带手动干预）。

其中一个技巧是PR流水线如何决定将PR部署到哪个环境。我能想到三个选项：

1. 动态创建一个环境，一旦PR合并或关闭就会被删除。这是最先进和灵活的选项。这需要系统将环境位置发布到PR。

2. 拥有一组环境，并让自动化程序找出哪些是空闲的并自动选择一个。环境可以停止，因此您可以找到一个已停止的环境，启动它并在那里部署。一旦PR关闭/合并，再次停止环境。您可以将环境位置发布到PR。

3. 向PR添加标签，指示环境（即env-1、env-2等）。这是最简单的选项，但需要开发人员查看打开的PR，以查看其他PR中已经使用的环境，以避免覆盖其他人的代码。

有了所有这些选项，一旦创建了PR，您只需将新提交推送到分支，环境就会更新。

您还需要决定当新提交推送到主分支时要执行什么操作。您很可能希望触发新的PR构建，以使用最新的主分支更新环境，但是您可以根据主分支的繁忙程度自动或手动执行此操作。

- Francesc Castells

Answer 5

Nathan，添加一个开发分支是个好主意，你可以在新的分支上进行开发变更并在开发环境中测试它们，在获得签署后移动到生产环境时，你可以将你的变更合并到主分支中。

在发布你的代码安装到生产环境之前，别忘了对合并后的主分支进行回归测试，以确保旧功能和新功能都能正常工作。

- Gabriel Hernandez

---

嗨 Gabriel，感谢回复。但是在 GitHub Flow 中没有开发分支，只有 git flow 中才有。所以我的问题更多地涉及如何使用 GitHub Flow 创建开发环境（其中没有特定的开发分支）。因此，

当推送另一个分支时，请设置 GitHub 操作，以便将除主分支以外的任何其他分支部署到此环境中。

- Nathan Sainsbury