放行处和持续交付

Question

需求

• 我们有两个环境。-测试和推动
• 我们要进行持续部署。
• 我们正在使用Git流。

使用git流，我们应该在生产中部署发布(或主)分支。(两条不同的管道，一条用于连续集成(分支开发)，一条用于连续输送(支路主)。

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

我的想法是，是如果测试通过了开发。我会让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表示发布分支：

发布分支支持准备一个新的生产版本。它们允许在最后一刻点缀I‘s和交叉t’s，此外，它们还允许微小的错误修复和为发行版(版本号、构建日期等)准备元数据。通过在发布分支上完成所有这些工作，开发分支将被允许接收下一个大版本的特性。

如果您的组的工作流与发布分支的用例不匹配，就不要使用它们。如果你后来发现你需要它们，那就开始使用它们。

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

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