continuous-integration - 发布分支和持续交付

Question

要求

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

使用 git-flow 我们应该在生产中部署发布(或主)分支。 (两种不同的流水线，一种用于持续集成(branch develop)，一种用于持续交付(branch master)。

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

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

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

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

Do we really need the release branch especially where we are not using feature toggles to separate releases ? ( there are multiple people working on the same project )

][2

引用

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

Answer 1

git-flow 关于发布分支的说法:

Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.

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

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

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