读书笔记：持续集成软件质量改进和风险降低之道-第一章

一个原则：针对每一次变更进行构建

变更：可能是代码的改动，可能是配置的改动，也可能是数据库模式等相关的改动，也有可能是编译环境的改动

经常构建对开发的好处：

1）所有的软件组成部分是否能协同工作？--通过build的结果，测试的结果可以完成

2）我的代码复杂程度如何？---这一块在目前的工作中好像还没有体现

3）开发团队是否坚持了已经指定的编码标准？---通过代码风格检查

4）自动测试覆盖了多少代码？---通过测试覆盖工具，目前这块好像比较少

5）在最后一次变更之后，是否成功了通过了所有的测试？

6）应用程序是否已经满足性能需求？

7）最近的开发是否存在问题？

以上没有注释的几点，个人认为必须将持续集成和后面的测试结合起来才能体现和回答这些问题。

关于测试环境，生产环境，开发环境和持续集成之间的关联

就重要性而言，生产环境应该是最为严格和优先级最高的，开发环境相对轻松，测试环境处于中间。那么如果和持续集成对应起来，开发环境应该是针对开发，更多的面向personal build，而测试环境应该是集成了不同开发人员的defect或者feature对应的code change 再编译所形成的版本，而生产环境则对应为production build。

这中间需要掌握的一个原则是：进入测试环境中的defect一定是在开发环境中通过build的，最好能进行冒烟测试，而进行生产环境的defect或者feature一定是在测试环境中通过测试验证的。

持续构建的终极目标：无人值守，与IDE无关，能够单独自动执行。因此千万不要以为你在IDE里面build或者自己跑个ant 命令就是持续集成，那只是持续集成的一小部分，最原始的手工作坊。持续集成并不单单指daily build和code持续集成到build中去。

需要说明的是持续集成的反馈机制也是非常重要的，以邮件，短消息的方式通知用户build的结果，手工也是一种方式，但太原始，需要过多的人工借入的都不算best practice

CI的几项特征：

1 与版本控制系统连接

2 构建脚本

3 某种类型的反馈机制

4 集成源代码变更过程

作为做了几年持续集成的人来说，我不得不说这个总结非常到位。真是缺一不可。不过个人认为应该再加一个：平台支持已经编译环境。这一点也非常重要，特别是在大型的产品集成过程中，需要花相当一部分精力在不同平台下编译环境的搭建上。这些环境也是CI中非常重要的一部分。

这里作者提到了数据库集成，但很遗憾的事我从事的项目中并没有把这一块单独分出来，而仅仅是和项目的其他component一样作为产品开发的一个部分，因此，即使有数据库的变更，最终也会和代码一起相同对待。对于这一点没有太多发言权

关于测试：书中提到没有自动化测试的，持续测试的CI不能算作真正的CI。这一点我是非常赞同的，但我觉得这里的测试可以理解为冒烟测试或者BVT（build verification test）或者开发环境中的单元测试等。而与广义的与开发相对应的测试概念有所不同，CI的目的之一是要保证最终出来的builld能快速deliver给相关的人员，如测试人员，因此在CI的环节中引入过多的测试例子并不妥当，这里的测试应该相对比较窄，仅仅针对核心功能做快速验证，以保证build基本是OK的。当然站在产品开发的角度，测试是不可避免的，如果这么理解也未必不可。

自动化的审查：一般指code style checking。是除了人工code review之后对代码风格的一种检测，从而从流程的角度上保证代码的质量。毕竟人工的code review还有很多不能确定的东西。市面上有很多这样的工具，Python的pylint，Java的Checkstyle。如果能在持续集成中加入这个环节，对产品的质量又多了一道保证。

部署没啥说的。这是CI少不了的一部分，产品的最终打包等。这个过程包含的范围可宽可窄，也许在测试环境中，build只需要是一些安装包或者zip包的形式即可，但如果到生产环境，甚至是跟客户deliver相关的，那么可能设计到ISO的生成，文档等。但后面这个过程一般会由专门的release 团队来完成，它在某种程度上说已经超过CI的范围