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

Question

我在一个项目中工作，我们有Live，RC和QA。当QA团队测试故障单的功能时，个别问题会进入QA。一旦票证通过，它就准备好转移到RC。在发布之前，我们会考虑所有已准备好的问题并将它们全部放在RC上，以确保票证不会导致彼此出现问题。一旦完成所有RC移动一起生活。

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

我们目前的流程：

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

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

更新

我们的流程可以使门票A进入QA环境并停留一段时间。可以开发票证B，移动到QA，QAed和RC并在票证A离开QA环境之前释放。这不是现在可以改变的东西。我正在寻找适合我们需求的解决方案。我有能力在存储库级别影响我们的流程实现，但不能立即以显着的方式修改所有流程。

Answer 1

我认为您最好的选择是审核Mercurial的建议workflows。我可以根据自己的经验告诉你，结构化的发布周期中有代码（功能，增强功能和错误修复）进入QA环境进行验证和准备发布，然后从这些发布标签中分支出来用于紧急补丁，Mercurial非常适合。

对于我在下面的步骤，“trunk”正是其他人可能称之为主线的。 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"然后hg branch "name of branch"（可能与标记匹配）从已发布的标记修订（例如1.0.0）创建分支名称）。
9. 在分支修订版“on”上，修复bug，提交，将其合并到“trunk”。
10. 从分支上的最新版本进行构建，并将其推送到QA。
11. 如果测试成功，可以将该构建移动到UAT并根据需要进行生成，您可以确信您只发布了一个错误修复。

所有这些，新的功能，功能和非关键错误修复都可以在“trunk”中完成，继续按照计划发布的“下一个”版本的代码。