发布分支和持续交付

Question

要求

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

使用git-flow，我们应该在生产环境中部署release（或master）分支。 （两个不同的管道，一个持续集成（分支开发），一个用于连续传递（分支主）。

应该如何使用我的版本分支？

我心目中是，如果测试通过开发，我会让CI服务器创建一个发布分支提交，并将更新的发布分支部署到我的产品分段插槽中，经过业务批准后其中一个发布点将被部署到产品中

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

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

我们真的需要发布分支特别是在我们没有使用功能切换到独立版本？ （有许多人在同一项目上工作）

] [2

参考

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

Answer 1

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

如果您正在进行真正的连续发布，那么您可能会跳过很多测试，因此即使拥有发布分支也没有什么大问题。风险很大，但如果它符合你的模型，你就可以做到。

Answer 2

混帐流说，关于发布分支：

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

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

我们在我工作的一个组中使用git-flow。通常我们只有一个或两个开发人员在维护项目上工作，而且我们很少需要同时修复错误并添加功能。除非我们有特定的场景，否则我们不会使用发布分支。

总的来说，我喜欢你设置的管线。