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

Question

对于一个由 12 名开发人员组成的团队，您能否帮助我确定使用 Mercurial 进行源代码控制并使用 team city 进行构建服务器来构建和部署产品的流程和工作流程？

我们有一个跟踪问题和增强请求的系统。其中大多数都是非常小的错误，并且由一名开发人员在一两天到一周的时间范围内进行了改进。我想要完成的是让业务人员和 IT 管理层就开发人员工作的票证的优先级进行协商。完成后，这些更改将被提交并推送到中央存储库，并在票务系统中标记为开发完成。然后，质量保证和业务团队应该能够从标记为开发完成的票证中进行选择，并根据优先级、必要的质量保证数量和质量保证资源可用性将其包含在我们下一个版本的产品中。

我最初认为我可以通过让开发人员在每个票证的新命名分支上提交更改来实现此目的。这样，每个选定票证的分支都可以 merge 到默认值，并且可以执行构建和部署到质量保证(以及最终的生产)。

问题在于持续集成。在我看来，我只能静态配置 teamcity 来构建我们中央存储库中的特定分支。也许这是我们所在的 teamcity 版本的限制。目前使用的是 5.0.3，但升级是一种选择(而且我们可能会这样做)。也许有一些棘手的方法可以让它从尖端构建，因此在触发构建的提交发生的分支的头部？如果开发人员正在为所有内容提交并推送不同的分支，并且这些分支直到一段时间后才会 merge 到默认分支中 - 足够晚，质量保证现在正在等待这些更改来构建，如果存在损坏的构建，则成本会更高- 没有一个特定的分支可供我们进行持续集成构建。

也许我让这个变得过于复杂和/或忽略了一些简单的事情。感谢帮助。有没有一种方法可以完成这种选择性的发布集成，并且在开发人员进行推送时仍然具有持续集成？

Answer 1

使用 Jenkins(以前称为 Hudson)，开发人员可以轻松复制现有作业(例如:在“默认”分支中构建最新头的作业)并进行小更改(例如:在“默认”分支中构建最新头的作业) “吉姆”分支)。 (尽管阅读上面我关于为什么命名分支可能不是您正在做的事情的正确选择的评论)。想必 teamcity 也有类似的东西。

另一条路线是按照您所说的那样进行，并且让构建器始终构建“提示”，无论分支如何。您可以通过输入“tip”作为分支名称来实现这一点。它不是分支说明符，但 teamcity 可能只是执行 'hg update -C -r BRANCHNAME' 和 'tip' 在那里工作得很好。