Mercurial工作流程，具有选择性特性部署和持续集成。

Question

针对一个由12位开发人员组成的团队，请问您能够帮助我确定一种建立和部署产品的流程和工作流吗？我们使用Mercurial进行源代码管理，并使用TeamCity作为构建服务器。我们有一个跟踪问题和增强请求的系统，其中大多数是由一名开发人员在一天或两天到一周的时间内处理的相当小的错误和改进。我的目标是让业务部门和IT管理层协商决定开发人员可以处理哪些问题。完成后，这些更改将被提交并推送到中央代码库，并在问题跟踪系统中标记为“已完成(dev complete)”状态。然后，QA和业务团队应该能够从已标记为“已完成(dev complete)”的问题中选择，并根据优先级、所需QA量和QA资源可用性将其包含在我们的产品中，以供下一版本发布时使用。

原本我打算通过让开发人员在每个问题(ticket)上创建一个新的命名分支(branch)，来实现此功能。这样，每个被选中的问题的分支(branch)可以合并(default)并构建和部署到QA(最终生产环境)。

但问题在于持续集成(Continuous Integration，CI)。我认为我只能静态地配置TeamCity以从我们中央代码库的特定分支(branch)上构建。也许这是我们使用的TeamCity版本的限制。目前我们使用的是5.0.3版本，但可以升级(version upgrade)。也许有一些巧妙的方法可以使其构建并基于提交触发构建的分支(branch)的头(top)而非特定分支(branch)？如果开发人员在不同的分支(branch)上提交和推送所有内容，并且这些分支(branch)直到一段时间之后才合并(default)，直到QA需要等待这些更改构建出来并且如果有破坏性(build broken)的构建成本会更高，那么我们就没有一个特定的分支(branch)可以进行持续集成构建。

也许我正在把这件事情复杂化或者忽略了一些简单的东西。希望得到您的帮助。是否有一种方法可以实现选择性集成(Selective integration)以进行发布，并在开发人员提交(push)时仍然进行持续集成(CI)呢？

- Dave Rael

---

命名分支不适合用于短期的错误修复和功能开发。它们更适合用于永久性的概念，如“稳定”和“实验性”，并使用标签进行发布。请阅读http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/。 - Ry4an Brase

Answer 1

使用Jenkins（前身为Hudson），开发人员可以轻松复制现有的作业（例如，构建“default”分支中最新版本的作业），并进行小的修改（例如，构建“jim”分支中最新版本的作业）。 （但请阅读我上面的评论，了解为什么命名分支可能不适合您要做的工作）。据推测，TeamCity也有类似的功能。

另一种方法是按照你所说的那样，让构建器始终构建“tip”，而不管分支如何。您可以通过将“tip”作为分支名称输入来实现这一目标。虽然它不是一个分支说明符，但TeamCity很可能只是执行'hg update -C -r BRANCHNAME'操作，并且'tip'在这里完全有效。

- Ry4an Brase

---

这个可以运行，但需要注意的是，如果两个开发者同时推送代码，并且时间间隔很短，TeamCity会跳过第一个。 - Lasse V. Karlsen

我也在Jenkins中看到过这种情况。分开的任务可以避免这种情况，但是始终如一的方法仍然容易受到影响。 - Ry4an Brase

感谢大家提供的信息。我会在构建配置中尝试一下将提示信息抛出到分支中进行实验。从未想过如此简单的方法竟然可行。我也理解了有关命名分支的观点，会考虑并与我的团队讨论。我会回来报告结果并接受答案。 - Dave Rael

只是插入提示并没有起作用。我还会再尝试一下，看看是否能够想出一个欺骗它的方法。 - Dave Rael

Answer 2

我已经得出结论，我尝试走的方向行不通。必须用另一种方法来完成这个任务。

- Dave Rael