引入持续集成

看到这里，你一定想要尝试一下持续集成了。但是从哪里开始呢？我在上面描述了一整套的实践，这些可以让你体验到所有的好处。但你也不必一开始就照单全收，你有自己的选择余地，基本上取决于你的环境和团队的特性。我们也从过去的实践中吸取了一些经验和教训，做好下面这些事会对于你的持续集成运作有重要的意义。 最早的几步之一是实现 build 自动化。把所有需要的东西都放进版本控制系统里，这样你就可以用一条命令 build 整个系统。这对许多项目而言不是什么小任务，这对于其他东西正常工作非常重要。刚开始你可能只是偶尔需要的时候做一个 build，或者只是做一个自动的 nightly build。当你还没有开始持续集成时，自动 nightly build 也是一个不错的开始。 其次是引入一些自动化测试到你的 build 中。试着指出主要出错的地方，并要让自动化测试暴露这些错误。建立又快又好的测试集合会比较困难，特别在已存在的项目中，建立测试需要时间。你必须找个地方开始动手，就像俗话说的，罗马不是一天建成的。 还要试着加快提交 build 的速度。虽然需要几个小时 build 的持续集成也比什么都没有好，但能做到传说中的10分钟会更好。这通常要对你的代码动一些大手术，以剥离对运行缓慢那部分的依赖。 如果你刚刚开始一个新项目，从一开始就用持续集成。对build时间保持关注，当慢于10分钟时就立即采取行动。通过快速行动，你可以在代码变得太大之前做一些必要的架构调整。 比所有事情都重要的是寻找帮助。找一个以前做过持续集成的人来帮你。像所有新技巧一样，当你不知道最终结果怎样的时候会非常难以实施。请一个导师（mentor）可能会花些钱，但如果你不做，你会付出时间和生产效率损失的代价。（免责声明/广告：是的，我们 ThoughtWorks 在这个领域提供咨询服务。不管怎样，我们曾经犯过你可能会犯的大多数错误。）