使用 GitHub 流的开发和生产环境

Question

在工作中，我们现在使用 GitHub，并使用 GitHub 流程。我对 GitHub Flow 的理解是有 master 分支和 feature 分支。与git flow不同，没有develop分支。

这在我们已经完成的项目上非常有效，并且简化了事情。

但是，对于我们的产品，我们有一个开发和生产环境。对于生产环境，我们使用master分支，而对于开发环境我们不知道该怎么做？

我能想到的唯一想法是：

1. 当分支与 master 合并时，使用 GitHub 操作重新部署 master。
2. 推送另一个分支时，设置一个 GitHub 操作，以便将任何其他分支（master 除外）部署到此环境。

目前，对于需要开发环境的项目，我们基本上使用的是 git flow（功能 -> 开发 -> 主控）。

您认为我的想法是否合理，如果不合理，您会推荐什么？

编辑：

澄清一下，我问的是使用 GitHub Flow 而不是 git flow 实现开发的最佳方式。

Answer 1

根据我的经验，具有多个环境的 GitHub Flow 是这样工作的。合并到 master 不会自动部署到生产环境。相反，合并到 master 会创建一个构建工件，该工件可以通过使用 ChatOps 工具的环境进行升级。

例如，推送到master 会创建一个名为my-service-47cbd6c 的构建工件，它是服务名称和短提交哈希的组合。这被推送到某种工件存储库。然后可以使用诸如 ChatOps 风格的斜杠命令之类的工具将工件部署到各种环境中以触发 deloy。例如，该工具还可以进行检查以确保不会跳过测试环境。最后，将工件提升到生产环境。

因此，对于您使用 GitHub Actions 的用例，我的建议是：

1. 推送到master 会创建构建工件并自动将其部署到开发环境。
2. 开发中的测试
3. 通过使用斜杠命令部署到生产环境来提升工件。 slash-command-dispatch 操作将帮助您解决此问题。

Answer 2

您也可以考虑 environments 的概念（如 illustrated here）

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

##Limit which branches can deploy to an environment

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

当作业尝试部署到配置了部署分支的环境时，Actions 将根据配置检查 github.ref 的值，如果不匹配，作业将失败并停止运行。

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

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

这意味着您可以定义要在开发环境中部署的作业，并且作为条件，该作业仅在从给定分支推送的提交触发时才会运行（在您的情况下为master）

Answer 3

对于任何面临相同问题或希望简化流程远离 gitflow 的人，我建议您查看 this article。虽然它没有明确谈论 Github 流，但它确实有效地为 OP 提供了一种解决方案。

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

我认为Gitflow intro 的写法也相当实用：

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

文中的图总结的很好：

所以这里我们有 Master == Gitflow main，有用的补充是临时发布分支，您可以从中部署到其他环境，例如开发。值得考虑的是您选择将此临时分支称为什么，在上面它被认为是一个发布，在您的过程中它可能是一个测试分支，等等。

您可以接受或离开压缩和标记，并且工具将在团队之间发生变化。同样，您可能关心也可能不关心实际版本号。

这与 VonC 的答案相距一百万英里，不同之处在于流程定义更严格，更倾向于让多个开发人员合并到一个分支并应用修复，以便为生产准备好新版本。很可能您通过命名约定来配置这个临时分支的部署，如他的回答。

Answer 4

Nathan，添加一个开发分支是个好主意，您可以在新分支中处理开发更改并在开发环境中测试它们，在获得签核以转移到生产环境后，您可以在主分支中合并您的更改。

不要忘记在合并后的 master 分支上执行回归测试，以测试旧功能和新功能都可以正常工作，然后再发布代码以在生产中安装