testing - Mercurial - 提供独立的功能进行测试和上线

Question

我们将切换到 Mercurial。我们计划中缺少的一个部分是如何管理构建到 Test Box(和 LiveBox)的分支/merge ，以便隔离的功能可以与 StableRelease 混 merge 构建到 TestBox。

例如，似乎主要的用法是有

• DefaultStableBanch
• • 测试库
• • • FeatureABranch
• • • FeatureBBranch

FeatureA 和 FeatureB 的开发将同时进行。看起来主要的用途是使用带有上述分支的克隆存储库。

场景 1:如果我们构建测试，我们将 merge LiveCode+FeatureA+FeatureB。如果一切顺利，那么我们可以将变更集 merge 到上游的 DefaultStable 分支，并使用 FeatureA 和 FeatureB 构建到 LiveBox。工作完成。

场景 2:如果我们构建测试，我们将 merge LiveCode+FeatureA+FeatureB，QA 显示 FeatureB 存在问题。我们不想再构建 FeatureB。我们确实想要推进 FeatureA。我们想单独重新测试 FeatureA 并让 QA 通过。然后将其发布到 Live，从而实现业务敏捷性。

问题:如果 FeatureB 未通过 QA，我们需要从测试分支中取出 FeatureB 变更集节点，再次构建到 TesBox，然后希望将上游 merge 到 DefaultStable 分支到 LiveBox。
从 TestBranch 中删除 FeatureB 变更集节点的最佳方法是什么，因为 1. 我们需要在 FeatureB 上进行更多开发，而 FeatureB 节点集尚未完成。2. 我们需要隔离 DefaultStable+FeatureABranch 并构建它来测试

其他人如何管理它？

Answer 1

有很多关于 Mercurial 工作流程的精彩文章，包括:

• > http://stevelosh.com/blog/2010/02/mercurial-workflows-branch-as-needed/
• > http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/
• > https://www.mercurial-scm.org/wiki/StandardBranching

所有这些都使用 Named Branches非常简单——绝对不是每个功能一个，克隆作为分支听起来像是您(和我)喜欢的工作模式。

针对您的具体问题，如果 LiveCode+FeatureA+FeatureB 组合测试失败，最好的处理方法是继续修复 FeatureB，然后将这些更改 merge 到 FeatureA + Feature B 中。但是，在您开始之前在那个阶段，让 QA 也分别点击 LiveCode+FeatureA 和 LiveCode+FeatureB 是个好主意，这对他们来说工作稍微多一些(更多测试目标)，但将每个功能隔离开有助于更快地找到缺陷的原因。

一旦 LiveCode+FeatureA 和 LiveCode+FeatureB 通过 QA，然后您将它们 merge 到 LiveCode+FeatureA+FeatureB 中，如果仍然通过测试，则将整个东西 merge 到 DefaultStable 中。应该没有必要从 LiveCode+FeatureA+FeatureB 中删除 FeatureB，因为您始终可以创建 LiveCode 的新克隆，并在需要时仅 merge FeatureA。

这是一篇关于基于 Mercurial (Kiln) 的 QA/发布流程的精彩文章:

http://blog.bitquabit.com/2011/03/10/when-things-go-well/