该帖子同步发自：(rockwave的博客  访问该博客)

所有讨论到敏捷开发模式的书籍或论文中，持续集成是一个必然被提到的问题，但是什么才是持续集成，怎么理解和应用，在每个公司肯定有一些不同的理解，进而有不同的实现方式。

对于软件项目开发来说，最直接的想法就是，项目开发人员每完成一个模块或者一个函数，甚至修补了一个缺陷，通过持续集成实现编译、测试、发布。这虽然只是一个非常粗略的描述，但是我觉得这已经达到了持续集成所应该完成的基本内容。按我的理解持续集成是一个项目开发的环境，这个环境让所在项目的每个成员可以比较快速的看到自己的代码是否能够和已存在的代码一起工作。

持续集成的环境应该是分层的，产品级别的、版本级别的、项目级别的。在不同层次上持续集成所起到的作用是不一样的，其最有用的应该是项目级别的，因为这直接关系到当前项目的进展，每个层级的持续集成环境，我觉得不应该耦合，应该相互独立，这不是有些人想象的，当完成了项目级的任务时可以自动的完成版本级的工作，耦合的越紧，那你在后期持续集成上面花费的时间和代价绝对可以抵消持续集成带来的收益，甚至会导致持续集成成为了项目开发的一种负担，这不是危言耸听，这是我的切身感受。

自从公司推行持续集成以来，首先是项目级别的后来要求版本级别的，产品级的由于代码权限以及部门壁垒的原因没有开始（幸亏没有做，否则会死人）。

我当时负责项目级别的持续集成环境工作，当这个项目结束时，项目成员虽然没有觉得它为项目带来很大的益处，但也没有因为它的引入而产生反感，甚至这时大家还觉得这是一个好的做法，只是有些实际操作还有些缺陷而已，但没有等我们将这些缺陷修补到下一个项目中，公司已经开始推行版本级的持续集成，而项目级的就此退出了江湖无人问津，所有的人都紧盯在了版本级上，项目级的持续集成只是一种形式了，只有在项目的一个功能完成时，做一次，将代码合入到版本级主线，执行一次形式上的版本级持续集成，这没有为项目带来任何的好处。

我现在甚至极端的认为持续集成只需要做到项目级就可以了，为项目级的持续集成搭一个框架，每一个新的项目只需要将其开发的基线代码以及相关附属文档替换框架中的路径就完事，其他的事情，让想干的人去干吧。

写这点东西的时候，我回忆了我们的整个过程，越想越觉得现在的公司持续集成已经成为了开发人员的一种负担，一种对持续集成的畏惧。