持续集成

在我早期从事软件行业的时候，软件项目中最尴尬和紧张的时刻之一就是集成。单独工作的模块被组合在一起，整个系统通常会以令人沮丧的方式失败，难以找到问题所在。然而，在过去的几年里，集成在很大程度上已经不再是项目痛苦的来源，它已经变成了一个无关紧要的事情。

这种转变的本质是更频繁地集成。曾经，每天构建被认为是一个雄心勃勃的目标。现在，我与之交谈的大多数项目每天都会集成很多次。奇怪的是，当你遇到一个痛苦的活动时，一个好的建议是更频繁地进行它。

关于持续集成的一个有趣的事情是，人们经常对它产生的影响感到惊讶。我们经常发现人们把它当作一个微不足道的益处，但它可以给项目带来完全不同的感觉。可视性大大提高，因为问题被更快地检测到。由于在引入故障和发现故障之间的时间更短，因此更容易找到故障，因为你可以轻松地查看发生了哪些变化以帮助你找到源头。再加上一个坚决的测试计划，这可以导致错误数量大幅减少。因此，开发人员花费在调试上的时间更少，而花费在添加功能上的时间更多，他们相信自己是在坚实的基础上进行构建的。

当然，仅仅说你应该更频繁地集成是不够的。在这个简单的口号背后，是一系列原则和实践，可以使持续集成成为现实。你可以在书籍和互联网上找到很多这样的建议（我很自豪地说，我自己也为这些内容做出了贡献），但你必须自己去挖掘。

因此，我很高兴看到 Paul 将这些信息收集到了一本连贯的书中，一本手册，供那些想要将这种最佳实践付诸实践的人使用。就像任何简单的实践一样，细节中有很多魔鬼。在过去的几年里，我们对这些细节以及如何处理它们有了很多了解。这本书收集了这些经验教训，为持续集成提供了与持续集成为软件开发提供的同样坚实的基础。