管道式的持续集成解决方案好吗？

敏捷开发的最佳实践之一就是持续集成，它使团队成员可以有规律地将他们的代码与基线集成并运行所有的单元测试和系统测试。在大多数团队中，当代码检入后， 持续集成服务器都能很快地自动完成这个工作。通常在项目初期一切都很顺利，但有时当团队或代码基线变得很大时，持续集成的速度就会开始下降。构建内容在增 加而反馈速度却在下降，构建一次可能要花上一小时甚至更多才能知道成功与否，而些时，有人可能已经将他们的代码检入到构建失败的版本中了。

为了解决这个问题，很多团队使他们的持续集成“管道化”，即分阶段进行构建。运行轻量级的构建，这个构建仅包括执行速度较快的那些测试，这样团队可以较快的得到初步结果，而更大范围的构建会在后台运行。而那些较慢的功能 / 集成 / 系统测试会在随后的阶段执行。 Simon Stewart 认为这种解决方案是有好处的：

这就是我们为什么最终会采用构建管道来做解决方案。较迟的构建比较早的构建会执行的更慢一些，但一切是按照能够提供更快反馈的方式来组织的。我们知道我们 只需要手工测试这些构建，让它们穿过管道的终点，假如我们向其中增加一些阶段，那么我们对应用程序按照预期方式执行的自信就会随之增加。如果我们足够聪明 （快看！我们又一次拉动了“聪明”这根杠杆！）的话，我们还可以把应用部署到越来越现实的环境中，并且把它当作管道的一部分来在上面运行测试，而这些是我 们在使用开发工作站时从来没有想到的事情。

然而，不是所有人都认为这是个好主意。 ThoughtWorks 的 Julian Simpson 把它叫做“厄运管道（pipeline of doom）”。他认为，我们是在用管道（一个慢速构建机制）来回避这个问题，而不是解决这个问题。这种方法只能给我们虚假的信心，认为我们的集成是成功的。开发人员一直在几个迭代中使用这些不好的代码，这只能加剧问题。

我发现管道方法存在另一方面的问题，那就是在开发者检入代码之前不会迫使他们运行功能测试，这就相当于你不让他们通过重构去改进代码。而假如大家运行它们 时感到痛苦的话，他们就有动力去解决它们。那些测试相当于给你当头棒喝：你必须小心又小心，否则，你可能在一天内只能运行很少的几次测试。

那么，你的团队使用了阶段化持续集成了吗？对你来说，效果如何呢？

查看英文原文： Is a Pipelined Continous Integration a Good Idea?