RM Build 在二元推广的基础上，而不是每个阶段的分支 . 我们的想法是让你从一个阶段升级到下一个阶段的 one 二进制文件集 . 这使得发布过程更快（没有发生无关的构建）并减少您的QA时间 - 如果您在QA中测试代码的功能，然后重建 生产环境 ，则会将 untested 二进制文件发布到 生产环境 中 . 它还有助于重复性 . 如果QA和Prod之间的发布失败，并且每个环境分支模型，您可能会对问题"Why did this work in one environment and not the other?"有额外的答案 . 这个问题的唯一答案应该是"because there's a problem with the environment" . 它永远不应该是"because we botched a merge" .
1 回答
RM Build 在二元推广的基础上，而不是每个阶段的分支 . 我们的想法是让你从一个阶段升级到下一个阶段的 one 二进制文件集 . 这使得发布过程更快（没有发生无关的构建）并减少您的QA时间 - 如果您在QA中测试代码的功能，然后重建 生产环境 ，则会将 untested 二进制文件发布到 生产环境 中 . 它还有助于重复性 . 如果QA和Prod之间的发布失败，并且每个环境分支模型，您可能会对问题"Why did this work in one environment and not the other?"有额外的答案 . 这个问题的唯一答案应该是"because there's a problem with the environment" . 它永远不应该是"because we botched a merge" .
您应该重新评估分支策略，以便构建和释放一个分支，而不是依赖多个分支中的多个构建 .
也就是说，如果你现在不能搞乱你的分支策略，那么为每个分支创建单独的发布路径和模板的方法将是解决它的最佳方法 .
我通常做这样的事情，假设DEV - > QA - > PROD：
Dev分支进入开发环境 . QA分支进入QA环境 . Prod分支进入质量保证环境，然后进行 生产环境 .
这使得开发人员可以在前一版本稳定的同时继续开发新功能 . 如果你采用这种方法，你很快就会意识到QA分支是无关紧要的 - 你为发布而构建，然后测试你打算发布的东西 .
一旦你达到这一点，这是一条很短的途径，意识到最好保持dev分支短命，依赖于从dev到trunk的新功能的频繁合并 . 未准备好进行公共消费的更长时间运行的更改可以在功能标记后面进行隔离，因此您可以继续推出功能完整且经过测试的较小更改，同时仍在进行较长时间的开发工作 .