发布分支和持续交付
Release Branch and Continuous Delivery
要求
- 我们有 2 个环境。
-- 测试和生产
- 我们想进行持续部署。
- 我们正在使用 Git 流。
使用 git-flow 我们应该在生产中部署发布（或主）分支。 （两种不同的管道，一种用于持续集成（分支开发），一种用于持续交付（分支主机）。
我应该如何使用我的发布分支？
我的想法是如果测试在开发中通过。我会让 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
参考
通常，当您认为代码足够接近稳定时，我会 create/cut 一个发布分支。然后您需要改进该分支，直到它可以发布。在此之后您将进行广泛的回归测试，然后最终对其进行标记并发布。
如果你正在做真正的持续发布，那么你可能会跳过很多测试，所以即使有一个发布分支也没什么大不了的。它的风险更大，但如果它适合您的模型，您可以做到。
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。通常我们只有一个或两个开发人员在一个项目上进行维护，而且我们很少需要同时修复错误和添加功能。除非我们有特定的场景，否则我们不使用发布分支。
总体而言，我喜欢您设置的管道。
要求
- 我们有 2 个环境。 -- 测试和生产
- 我们想进行持续部署。
- 我们正在使用 Git 流。
使用 git-flow 我们应该在生产中部署发布（或主）分支。 （两种不同的管道，一种用于持续集成（分支开发），一种用于持续交付（分支主机）。
我应该如何使用我的发布分支？
我的想法是如果测试在开发中通过。我会让 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 )
参考
通常，当您认为代码足够接近稳定时，我会 create/cut 一个发布分支。然后您需要改进该分支，直到它可以发布。在此之后您将进行广泛的回归测试，然后最终对其进行标记并发布。
如果你正在做真正的持续发布，那么你可能会跳过很多测试，所以即使有一个发布分支也没什么大不了的。它的风险更大，但如果它适合您的模型，您可以做到。
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。通常我们只有一个或两个开发人员在一个项目上进行维护，而且我们很少需要同时修复错误和添加功能。除非我们有特定的场景，否则我们不使用发布分支。
总体而言，我喜欢您设置的管道。