持续集成和DVCS模式

我们目前使用Subversion和TeamCity，我们将转向使用Mercurial（特别是Kiln，因为我们是FogBugz用户）。

显然，这将导致我们的开发模式（我们两个人！）发生变化-希望有所改善-但我正在努力解决的一个问题是如何构建事物，以便我们仍然享受持续集成/我们的CI服务器的好处（已经存在并且将继续保持收益是给定的，对此问题的讨论不在此问题的范围之内。

借助SVN，我们致力于使用数量有限的中央存储库-每个项目实际上一个中央存储库（或多或少的一个Visual Studio解决方案），因此可以轻松触发构建并确保所有文件都已提交且没有任何内容但是，如果我们要充分利用Mercurial，我们将希望拥有更多的存储库实例，我希望这些更改通常会流向确定的“实时”存储库。我苦苦挣扎的问题是，对于我来说，实时回购似乎太“迟到”，无法触发我的CI构建OTOH每个开发人员每个项目一个CI构建可能会过多（并导致其他问题）。

我在钓鱼，但是那是因为中央颠覆仓库提供的一件事（我，在我们的设置下！）非常清楚什么时候建造。

nb我不是在问将Mercurial与持续集成结合使用的机制-我想为个人项目，模式和结构以及工作实践/工作流程做些准备，以求达到目标。

首先，在TeamCity中每个项目具有多个版本确实是可行的方法。该平台的性质非常容易-复制按钮在那里是有原因的。

无论如何，当我们使用SVN时，我们通常会为每个项目运行2个构建-一个指向主开发线（在我们的情况下为主干），另一个指向发布分支。我们遵循类似于此分支模型的分支模型，将此构建设置移交给了HG 。既然我们不能再使用当前的SVN版本号，那么唯一的挑战就是找到有关内部版本号的新功能。

我们尝试并鼓励人们相对频繁地推动工作，尤其是当同时进行大量工作并且我们希望更快的反馈周期时。仅仅因为它是DCVS，并不意味着您每天只需要推一次。

我们已经使用Kiln大约一年了，并尝试了几种不同的方法。我们最终要使用具有以下分支策略的命名分支（而不是分支克隆）：

• 默认跟踪“完成”的开发
• 功能分支跟踪当前正在进行的工作
• 释放我们从默认位置释放的分支跟踪点

因此，工作是从default的当前提示创建功能分支开始的。当特性分支完成*，分支被关闭，合并到默认值。

在某个时候，我们决定已准备好发布，因此我们从default的当前提示创建一个新的发布分支。这使我们可以通过提交到release分支来更改当前正在生产的代码，同时仍然允许在功能分支和default上进行主动开发。

对于持续集成，我们做两件事：

• 监视默认状态的“始终在线”集成
• 每个发行分支的新集成

在默认的分支工作让我们知道，我们的主要源代码树总是稳定-在发布分支的工作让我们知道这些分支是稳定的，并为我们提供了我们需要推动释放投产生成输出。

_{*我们对“完成”的定义是该功能是最新的，具有默认合并功能，并且已在代码审查中得到批准。}

如果您迁移到Hg之类的DVCS，则不仅会获得“分布式部分”，还将获得良好的分支和合并的全部功能。

考虑到现在您将拥有一个好的问题跟踪器和一个好的SCM ...为什么不为每个任务创建一个分支？

“每任务分支”模式并不是新的（请参阅Berczuk的书），但是绝对可以尝试。

我详细解释它在这里，和优点和CI的利弊与“控制” 在这里。