Requirements
-
我们有2个环境 . - 测试和产品
-
我们想要进行持续部署 .
-
我们正在使用Git Flow .
使用git-flow，我们应该在 生产环境 中部署发布（或主）分支 . （两个不同的管道，一个用于连续集成（分支开发），一个用于连续交付（分支主管） .
How should I use my release branch ?
What I have in mind 是测试是否通过了开发 . 我会让CI服务器创建一个发布分支提交 . 并将更新的发布分支点部署到我的制作暂存插槽 . 业务审批后 one of the release points 将部署到 生产环境 中 .
这意味着 I am letting CI server automatically create a release-branch 并重新运行 生产环境 环境的临时插槽上的所有测试 . 如果失败，它将报告并删除发布分支，否则将创建发布点，触发网络交换并将其合并到主服务器 .
这种方法的优缺点是什么？什么是最佳做法？
我们真的需要发布分支，特别是在我们没有使用功能切换来分离版本的情况下吗？ （有多个人在同一个项目上工作）
] [2
Reference
-
功能切换，Youtube，https://www.youtube.com/watch?v=gxm1C92XhCQ
-
成功的Git分支模型，http://nvie.com/posts/a-successful-git-branching-model/
2 回答
通常，当您认为代码足够接近稳定时，我会创建/剪切发布分支 . 然后你需要优化那个分支，直到它准备好发布 . 在此之后，您将进行广泛的回归测试，然后最终标记并释放它 .
如果你正在进行真正的连续发布，那么你可能会跳过很多测试，所以即使有一个发布分支也没有什么大不了的 . 它风险更大，但如果它适合您的模型，您可以做到这一点 .
关于发布分支的git-flow说：
如果您的组的工作流程与发布分支的用例不匹配，请不要使用它们 . 如果您以后发现需要它们，请开始使用它们 .
我们在我工作的一个小组中使用git-flow . 通常我们只有一个或两个开发人员正在进行维护项目，我们很少需要同时修复错误并添加功能 . 除非我们有特定的情况，否则我们不使用发布分支 .
总的来说，我喜欢你正在设置的管道 .