粗略翻了一遍jolt大奖书籍《持续集成：软件质量改进和风险降低之道》，发现基本原则和我前面在做的并无差别，不过对方显然是百试不爽经验丰富，我在具体操作的过程中却停下了无数次，按照阳明先生的话来说，不能实践的知，实在不是真知，结合自己的认识，把读书后获得的一点小的总结放到后面，用来逐步改善自己的工作。
实现持续集成的第一个要点，简言之就是需要实现“一键构建”，展开来说那就是“在任何情况下，都能根据需要，从指定的服务上获得无二义性的一份材料来顺利完成这个构建过程”。这个讲起来有点抽象，不过拆开分为几层意思来说就明了了，要获得无二义性的构建材料，包括代码、配置等，那么肯定就需要版本管理工具的介入了，如集中式管理代码的svn，分布式管理代码的git，都是这类工具中的翘楚；获得了可靠的素材，构建还需要隔离环境或者配置变化带来的伤害，比如在开发者自己机器上运作构建，而不能运行到服务器上，那么就不是好的构建，这个时候需要通过一些配置项来调整平台或者其它构建环境的差别；第三个从这里引申出来的要点，那就是构建不能依赖于具体的IDE，因为这并非是所有环境都应该有的东西，这点我体会尤深。
持续集成的第二个要点，就是在上面第一点的基础上，需要在构建过程中，必须加入能够度量产品质量的一系列工具或过程。这点就很好理解了，持续集成不是为了持续的编译代码，或者说不只是。更多的是监控在变化的过程中，是否引入了复杂性、重复度、不好的代码风格、隐藏的bug。这些都是一个产品健康与否的关键指标，恰如一个人的身高体重血压，只有具备了这些过程，构建才能对产品形成一个客观的报告，在这方面我用过的工具就有sonar，pmd，checkstyle，findbug等，当然，这里有一个并非现成的工具，而需要开发者辛勤的去积累的一个东西，那就是对于产品的自动化测试代码，根据我的实践，在一个既有代码全无测试的工程里加入测试，背负的历史包袱不可谓不重，报告里对代码测试覆盖率极低的数据，又会成为开发者最终放弃做单元测试的理由，这个大概可以用“破窗理论”来解释，一旦开发者觉得无望处理遗留的代码，他就有可能转为顺从历史，也放弃写测试，进而导致这个洞越来越大。这事我觉得较为靠谱的或许就是由开发者坚持对新功能加测试，然后对于出现问题的老代码加上测试，逐步进行。
然后是持续集成的第三个方面，这个点可以很自然的从第二点推导而来，既然我们视集成构建是一件“有用”的事，而非一个玩具或者一种时髦，那么第二步加入的度量报告就必须受到严肃的对待，这些数据必须及时的通知到对应的人员并及时处理。简单的一些原则包括：必须尽快修复失败的构建；开发者争取建立自己的私有构建过程，避免提交不能构建的东西到版本库等。通知和展现这个目前持续集成的工具都做的比较好。我用过的hudson及其各种插件能满足大部分场合的应用，最要关心的反而是人的环节，必须有人对持续集成产生的报告做持续的跟进，并及时抛出一些需要团队注意的问题，这样才能规避一系列的开发风险，提高开发的质量和效率。