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

【问题标题】：Mercurial - Delivering Isolated Features to Test and LiveMercurial - 提供独立的功能以进行测试和上线
【发布时间】：2011-07-15 00:04:27
【问题描述】：

我们将换成 Mercurial。我们计划中缺少的一部分是如何管理构建到 Test Box（和 LiveBox）的分支/合并，以便可以将独立功能与 StableRelease 混合并构建到 TestBox。

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

DefaultStableBanch
- 测试组
- - FeatureA 分支
- - FeatureB 分支

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

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

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

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

其他人是如何管理这个的？

【问题讨论】：

您是在 A 存在时预见到 B 的问题，还是 B 本身存在问题？还是两者兼而有之？
我试图防御 A 中的一个 Bug，A 的开发人员没有看到。但是，由 B 中的一些代码修复。因此，将 A 和 B 一起交付测试不会显示错误。释放 A 自行测试将显示该错误。也许对其他人来说似乎不太可能但是，ORM dal 在 A 和 B 之间共享，并且......聚合根是重要的共享代码片段，它们一直在处理可能导致这种情况的代码。此外，SQL 构建文件等...

标签： testing mercurial merge branch

【解决方案1】：

Mercurial 工作流程有很多很棒的文章，包括：

所有这些都极少使用Named Branches——绝对不是每个功能一个，将克隆作为分支听起来像是您（和我）更喜欢的工作模式。

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

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

以下是关于基于 Mercurial（Kiln）的 QA/发布流程的精彩文章：

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

【讨论】：

我也不建议命名分支，尽管我认为这就是您的意思。如果您不是在暗示这一点，那么我很抱歉。
干杯，感谢您的回答，我们将查看参考资料。在我看来，我假设在 Stable、Test 和 FeatureA、FeatureB 克隆中的默认测试分支。也许应该在所有 repos 中都应该有 FeatireA、FeatureB 名为 brancjes。这样我们就知道哪个 chnageset 节点在哪个 Feature ...
干杯，感谢您的回答，我们将查看参考资料。在我看来，我假设在 Stable、Test、FeatureA、FeatureB 克隆存储库中的 defaultStable、test 分支。也许在所有存储库中都应该有 FeatureA、FeatureB 命名的分支。这样，当 chnagesets 到达 defaultStable 分支时，我们就知道哪些变更集节点在哪个 Feature 中...？
@mikezx6r 我并没有试图纠正你的答案，我只是从不错过提供相关 Steve Losh 文章链接的机会，因为他非常清楚。
好的，我阅读了上面的参考资料。或许我们应该遵循 Mercurial 的做法，也许在一段时间后进行创新以获得更适合我们组织的东西。因此，我们可以使用名为 default for new dev 的分支。一个称为 stable 的分支，因为我们一次发布一个版本，不需要维护以前的版本。那些功能分支呢？以及要测试的构建？它应该混合{稳定分支头 + featureA 分支头 + featureB 分支头}。 ...

【解决方案2】：

在稳定的功能克隆分支中创建 FeatureA 和 FeatureB。测试只是 QA/Test 工作的临时区域，所以我从第一天起就将其视为“一次性”。

当 FeatureA 和 FeatureB 开发足够时，创建其中一个的克隆，并将另一个拉入 QA/Test。为 QA 进行构建，当他们提供反馈时，对 FeatureB 进行适当的更改。

如果 FeatureA 可以接受提升，将其拉入/推送到稳定版，然后合并到稳定版中。

这比我原来的帖子更清楚吗？

【讨论】：

我们将使用克隆。是的，这是显而易见的答案，但在我对 Mercurial 用法的研究中，没有明显的明确声明。似乎人们正在从测试分支分支 FeatureA 和 FeatureB 并坚持这个长期运行的测试分支。 A 以您的方式，也许您可以从 defaultStable 克隆中提取并推送到 Test Clone ... 请参阅底部的 hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html ... [paths]default = selenic.com/repo/hg default-push = hg.example.com/hg
问题是你找不到明确的答案，因为没有答案。 DVCS 的美妙之处在于它允许您以多种方式工作，并由您决定哪种方式最适合您的环境和限制。我将尝试将我的答案编辑得更具体，并提供几种替代方法。
是的，你的权利，没有正确的答案。干杯，感谢您的回答，我们正在尝试一些实验......