Git：使用A / B测试的DEV-QA-PROD循环的最佳实践是什么？

Question

我们刚搬到Git。 我们拥有数百万用户的实时产品。目前，我们从master为每个功能分支，当工作完成后，我们将其发布到QA进行测试。一旦获得批准，它就可以进行A / B测试@ 10％，相对于PROD中当前运行的版本（也是10％）。 如果一切顺利，我们会发布50％，然后是100％。

问题从以下时间开始：

1. 直到版本达到100％才需要几天时间。与此同时，我们继续努力 不同的功能，他们都从主人分支，所以当我们想要 发布A / B测试的下一个版本，基础版本是 不同（不包括最后一个版本的主人）。我们可以 在发布QA之前总是拉最新的，但我们不想 等待版本100％，这需要时间，现在QA将有 再次测试一切，因为它是一个不同的版本。
2. 如果我们决定从最新版本而不是从 master - 有时可以拒绝和删除最新版本 我们需要丢失所有最新版本的提交并返回 来源。

我想在等待A / B测试结果时，这个循环有很好的做法，我们很乐意阅读它们。

感谢。

Answer 1

看看这个架构：http://nvie.com/posts/a-successful-git-branching-model/

您正在寻找“发布分支” - 在项目进入QA时创建的分支。这样就创建了没有添加新功能的地方，只修复了错误。

我在我的项目中使用这个架构已经两年了，而且效果很好。

所有开发都在DEV分支中 - 新功能是基于DEV的分支。当您决定发布新版本的软件时，将功能分支合并到DEV中并创建新分支以供发布。这个版本分支是修复错误的地方，开发在DEV分支中进行。

您可以定期将发布分支合并到DEV分支，以便将错误修正包含在开发版本中。当您决定发布新版本，然后将发布分支合并到DEV以保留所有错误修正并将发布分支合并到主数据。