具有多个非实时环境的 Mercurial 工作流程

Question

我从事的项目有 Live、RC 和 QA。当各个问题准备就绪后，质量检查团队会测试票证的功能。一旦票证通过，就可以转移到 RC。在发布之前，我们会将所有已准备好的问题放在 RC 上，以确保票证不会相互造成问题。一旦完成，所有 RC 都会搬到一起生活。

使用 Mercurial 处理此问题的好方法是什么？我们当前的流程存在一些问题。

我们当前的流程：

Live 运行默认值，RC 运行默认值（实时）创建的分支，QA 运行它自己的分支（主干），该分支是过去从默认值分支出来的。

问题从默认分支，工作，然后合并到主干。一旦票证准备好进入 RC，它就会合并到即将发布的分支中。当进行测试时，发布分支将合并到默认分支中，默认分支将合并回主干中。我们遇到的问题是，一段时间后发生了一些事情，所有的冲突都会合并到主干中。如果我们在该合并中解决与主干的冲突，它往往会更快地破坏主干，如果我们有冲突，我们会将默认值合并到我们的分支中并在该提交中解决它们。这通常有效，但几周或几个月后主干似乎坏了，我们无法再解决冲突。

更新：

我们的流程是这样的，票证 A 可能会进入 QA 环境并在那里停留一段时间。票证 B 可能会在票证 A 离开 QA 环境之前开发、移至 QA、QAed 和 RC 并发布。这不是现在可以改变的事情。我正在寻找适合我们需求的解决方案。我有能力在存储库级别影响流程的实施，但目前没有能力以显着的方式修改整个流程。

Answer 1

我认为您最好的选择是查看 Mercurial 建议的工作流程。我可以根据我自己的结构化发布周期经验告诉您，该周期的代码（功能、增强功能和错误修复）将进入 QA 环境进行验证和准备发布，然后从这些发布标签分支到紧急补丁，Mercurial 非常适合。

对于我下面的步骤，“主干”就是其他人可能所说的主线。 Mercurial 中没有任何术语“主干”。您只有正在使用的存储库，它要么只是您的本地存储库，要么是另一个存储库的克隆（仍然是本地的）。

1. trunk是大家一般工作的地方。
2. 当特定的更改完成时，它会被推送到中央服务器（仍然是主干，中央服务器是可选的，只是通过持续集成使工作流程更容易）。
3. 从中央服务器存储库，构建完成并推送到 QA 服务器。
4. QA 测试功能，并且通常还应该测试已知变更之外的有限交互。
5. 如果变更通过了 QA 测试，发布经理可以选择将该变更集标记为要发布的版本号（hg tag "name of tag"）。
6. 一旦代码被标记并准备好发布，就可以进行另一个构建以推送到模拟生产配置的用户验收测试环境（UAT）。
7. 如果 UAT 通过，则可以完成最终构建并投入生产。请注意，您可以通过使用仅保存软件的预构建副本的单独“构建”存储库来节省一些构建步骤。这样，如果 QA 和 UAT 测试通过，则在投入生产之前只需要完成一次构建。
8. 如果在生产版本中发现缺陷，则可以使用 hg update "tag name" 然后从已发布的标记版本（例如 1.0.0）创建分支，然后使用 hgbranch "name分支”（可能应该与标签名称匹配）。
9. 当“在”分支修订上时，修复错误，提交，并将其合并到“主干”。
10. 从分支“上”的最新版本进行构建并将其推送到质量检查。
11. 如果测试成功，则可以根据需要将该构建移至 UAT 和生产，并且您可以放心，您只发布了单个错误修复。

一直以来，新功能、特性和非关键错误修复都可以在“主干”中完成，继续按计划发布代码的“下一个”版本。