持续集成_1_引子

出于对产品质量、开发效率的考虑，公司要在日常的开发过程中引入持续集成。

持续集成这个概念其实很多人都应该很熟悉，或者接触过很久。其实公司以前也做了很多这方面的工作，但是一直存在着一些问题。

就是很多人对其抱着无所谓的态度，每天定时的将代码代码提交到trunk，让服务器去整一些事情，然后立马关电脑下班，出了问题明天再说。更有甚者，对其抱有抵触的情绪，觉得浪费了很多时间，不如好好多写几行代码，改几个bug。

当然了，也有人支持，但是认为持续集成就是编译，保证提交的代码能够通过MSBuild的编译，或者在出错的时候收到一封邮件，及时修正一下提交的错误就OK了。

其实这些想法也不是没有道理，早些年，在没有持续集成的时候，甚至是在没有需求、测试人员的日子里，我也见过两三个人做出一个产品卖给政府部门，出了问题及时派个人过去糊弄一下，公司一样年收几百万。

但是随着网络、技术的发展，不说客户对产品的需求越来越高。就是开发人员自己，估计也很难忍受自己的代码三天两头出个问题，看着自己的代码在一堆的构建、测试、仿真、生产环境，产品出各种各样稀奇古怪的问题。也很难好意思再对技术支持人员说一句“这个问题不清楚，跟客户解释一下，先手工处理，以后再慢慢解决”了吧。

当然，持续集成也不是灵芝，包治百病的那种，甚至他都不是药，治不了你任何病，但他能发现你身体的很多毛病并且及时的通知你。你不听的话他会阻碍你做任何事情。直到你把问题解决了，你才能继续的工作生活。

说了半天废话，下一篇进入正题。