发布分支和持续交付

Question

要求

• 我们有2个环境。 - 测试和产品
• 我们想要进行持续部署。
• 我们正在使用Git Flow。

使用git-flow，我们应该在生产中部署发布（或主）分支。 （两条不同的管道，一条用于连续集成（分支开发），另一条用于连续交付（分支主机）。

我应该如何使用我的发布分支？

我想到的是，如果测试通过了开发。我会让CI服务器创建一个发布分支提交。并将更新的发布分支点部署到我的制作暂存插槽。在业务批准后，其中一个发布点将部署到生产中。

这意味着 我让CI服务器自动创建发布分支 并重新运行生产环境的暂存插槽上的所有测试。如果失败，它将报告并删除发布分支，否则将创建发布点，触发网络交换并将其合并到master。

这种方法的优点和缺点是什么？什么是最佳做法？

  

我们是否真的需要发布分支，尤其是我们没有使用功能切换到单独的版本？ （有多个人在同一个项目上工作）

] [2

参考

• 功能切换，Youtube，https://www.youtube.com/watch?v=gxm1C92XhCQ
• 成功的Git分支模型，http://nvie.com/posts/a-successful-git-branching-model/

Answer 1

git-flow谈到发布分支：

  

发布分支机构支持准备新的生产版本。他们允许最后一刻点缀我和交叉t。此外，它们允许修复小错误并为发布准备元数据（版本号，构建日期等）。通过在发布分支上完成所有这些工作，开发分支将被清除以接收下一个大版本的功能。

如果您的论坛工作流程与发布分支机构的使用案例不匹配，请不要使用它们。如果您以后发现需要它们，请开始使用它们。

我们在我工作的一个小组中使用git-flow。通常我们只有一个或两个开发人员在进行维护项目，我们需要同时修复和添加功能。除非我们有特定的情况，否则我们不会使用发布分支。

总体而言，我喜欢您正在设置的管道。

Answer 2

通常，当您认为代码足够接近稳定时，我会创建/剪切发布分支。然后你需要优化那个分支，直到它准备好发布。在此之后，您将进行广泛的回归测试，然后最终标记并释放它。

如果您正在进行真正的连续发布，那么您可能会跳过大量的测试，因此即使拥有发布分支也没有什么重要意义。它风险更大，但如果它适合您的模型，您可以这样做。