发布分支和持续交付答案

【问题标题】：Release Branch and Continuous Delivery发布分支和持续交付
【发布时间】：2017-06-09 00:53:59
【问题描述】：

要求

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

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

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

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

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

我们真的需要发布分支，尤其是在我们没有使用功能切换到单独发布的地方吗？（有多个人在做同一个项目）

][2

参考

【问题讨论】：

【解决方案1】：

git-flow 说的是发布分支：

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

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

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

总的来说，我喜欢您正在设置的管道。

【讨论】：

【解决方案2】：

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

如果您正在执行真正的持续发布，那么您可能会跳过很多测试，因此即使拥有发布分支也没有什么大不了的。它的风险要大得多，但如果它适合您的模型，您可以这样做。

【讨论】：