待定头部

我非常喜欢持续集成，这是一个相对简单的实践，可以为大多数开发团队带来巨大的改变。然而，就像大多数实践一样，它也有其缺陷^H^H^H^H^H改进的机会。Paul Duvall是该主题的即将成为标准书籍的作者，他最近指出了其中一个问题。如果提交构建失败，整个团队都会受到影响，并且可能在修复之前被减速。

当我们第一次在Thoughtworks开始做持续集成时，这是让我担心我们做事方式的事情之一。我担心的是，Thoughtworks 2000 风格和我们在C3中使用的风格之间存在着重要的区别。

Thoughtworks 2000 风格几乎是今天使用的 CI 的规范风格。当你对你的工作感到满意时，你把它提交到仓库，然后在构建机器上构建它（手动或使用像 CruiseControl 这样的 CI 服务器）。问题在于，如果你的提交不好，任何更新的人都会得到失败的代码，直到你修复它。

在 C3 的做事方式中，我们没有直接提交到仓库的头部。C3 是一个 Smalltalk 项目，使用 Envy，一个面向 Smalltalk 的仓库系统。Envy 有一些与主流仓库不同的概念。自从我使用它已经很久了，我对它到底是如何工作的记忆已经变得模糊了，但基本的想法是，当你正在开发你的功能时，你提交到版本。版本就像一个私有分支，每个人都可以看到，但没有被认可。只有当你在构建机器上成功构建后，你才会将你的版本升级到发布，这相当于主线。这样，你永远不会将错误的代码引入项目的 主线。

Envy 使得以这种方式工作变得容易，我们现在主要使用的版本控制系统使它变得更加棘手。理想情况下，你希望创建一个工作副本，它从真正的头部更新（以保持同步），但提交到不同的待定头部分支。只有成功的集成构建才能真正提交到真正的项目头部。一个持续集成服务器会从待定头部签出，如果成功，就会提交到真正的头部。

自己设置这样的东西有多难？我不确定，我没有和做过这件事的团队聊过。但是，许多面向团队的工具正在提供这种功能。例如，JetBrains 的 TeamCity 在“延迟提交”下执行此操作。Paul 还提到了 Borland 的 Gauntlet。

另一个问题是它有多重要。尽管我担心，我们在 2000 年没有因为构建失败而感到足够痛苦，以至于想要安装一个待定头部。如果你遇到很多构建失败的集成构建，还有其他方法可以解决。通常，主要问题是人们在提交之前没有进行私有构建。像往常一样，在引入更复杂的技术之前，处理人员问题通常是一个更重要的问题。