2014-03-01 81 views
1

我们刚刚搬到了Git。 我们拥有数百万用户的实时产品。目前,我们从每个功能的主人处分支出来,当工作完成后,我们将其发布到QA进行测试。一旦获得批准,它将在现场进行A/B测试@ 10%,而PROD中的当前运行版本(10%也是)。 如果一切顺利,我们发布50%,然后100%。Git:A/B测试的DEV-QA-PROD循环的最佳实践是什么?

  1. 直到版本去花费几天100%:

    的问题时开始。同时,我们研究了 的不同功能,它们都从主设备分支出来,所以当我们想要 发布A/B测试的下一个版本时,基本版本是 不同(不包括最新版本的主设备)。 总是会在发布到QA之前拉最新版本,但我们不希望 等待版本去100%,这需要时间,现在QA将有 再次测试所有内容,因为它是不同版本。

  2. 如果我们决定从最新发布的分支,而不是从 主 - 有时是最新版本,可以拒绝或删除 和我们要失去所有的最新版本,并承诺回去 原点。

我想在等待A/B测试结果时,这个周期有很好的做法,很想阅读它们。

谢谢。

回答

1

在这个模式请看下图:http://nvie.com/posts/a-successful-git-branching-model/

您正在寻找“发布分支” - 分支,它是在当时计划去QA创建。这创造了没有添加新功能的地方,只修复了错误。

我在我的项目上使用这个模式最近两年,它工作得很好。

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

您可以定期将发布分支合并到DEV分支,以将错误修正包括到开发版本中。当您决定发布新版本时,将发布分支合并到DEV以保留所有错误修正,并将发布分支合并到主。

+0

是的,我看到这个模式,但仍然无法确定这可能对我有帮助。 假设我创建了DEV,release和feature分支。现在我已经完成了一项功能并发布到QA。在发布批准之前,我已经创建了一个新分支,其中不包括发布到QA的更改。只有当最新版本获得批准并且100%进入PROD时,才会在PROD中进行测试,因此它必须包含以前的版本。 这意味着所有已完成的QA工作都没有意义。 谢谢。 – mrgoos

+0

回复更新,希望这个更清楚。请接受答案。 – Kacer