连续集成模式与DVCS

Question

我们目前使用Subversion和TeamCity，我们将转向使用Mercurial (特别是窑，因为我们是FogBugz用户)。

显然，这将导致我们的开发模式中的变化--希望是改进--(我们两个！)但是，我所困惑的一个问题是，如何构造事物，使我们仍然能够享受持续集成/我们的CI服务器的好处(有并且将继续有好处，这是一个给定的问题，对其的讨论超出了这个问题的范围)。

有了SVN，我们将致力于有限数量的中央存储库--实际上每个项目都有一个中央存储库(或多或少只有一个Visual解决方案)，因此很容易触发构建，并确保所有文件都已被交换，并且没有杂乱的依赖等等。但是，如果我们要适当地利用mercurial的优势，我们就需要有更多的存储库实例--在这里，我希望能够更改到最终的“实时”回购流程。我正在努力解决的问题是，在我看来，实时回购已经太晚了，无法触发我的CI构建OTOH，每个开发人员每个项目构建一个CI可能是过度的(并导致其他问题)。我认为live太晚了，因为我们可以/应该有更多的repos (克隆)，因此应该部署live，而我们希望在开发提交上构建/运行测试(单元提交，按计划间隔集成)。

我有一点钓鱼，但这是因为一个中央颠覆回购给一个东西(我，我们的设置！)很清楚什么时候该建什么。

n.b.我不是在问使用mercurial进行持续集成的机制--我需要为一个个人项目、它的模式和结构以及工作实践/工作流程而工作，这是我正在努力解决的问题。

Answer 1

首先，在TeamCity中每个项目有多个构建确实是可行的。这个平台的特性使得它变得非常容易--复制按钮的存在是有原因的。

在任何情况下，当我们使用SVN时，我们通常为每个项目运行两个构建--一个指向主开发线(在我们的例子中是主干)，另一个指向我们的发布分支。我们在遵循类似于这一个的分支模型的同时，将此构建设置传递到HG。唯一真正的挑战是找到一个关于构建号的新的恐惧schwea，因为我们已经不能再使用当前的SVN修订号了。

我们尝试并鼓励人们更经常地推动，特别是当有大量的工作同时进行，我们希望更快的反馈周期。仅仅因为这是一个DCVS，并不意味着你每天只能推一次或什么的。

Answer 2

如果你移动到DVCS，像Hg，你不仅得到了“分布式部分”，你也得到了良好的分支和合并的全部力量。

考虑到现在你会有一个很好的问题追踪器和一个好的单片机.为什么不为每个任务创建一个分支呢？

“每个任务分支”模式并不是新的(查看Berczuk的书)，但它肯定是值得尝试的。

我详细解释了这里，以及CI与“受控”这里的优缺点。