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

一个原则：针对每一次变更进行构建
变更：可能是代码的改动，可能是配置的改动，也可能是数据库模式等相关的改动，也有可能是编译环境的改动
经常构建对开发的好处：
1）所有的软件组成部分是否能协同工作通过build的结果，测试的结果可以完成
2）我的代码复杂程度如何-这一块在目前的工作中好像还没有体现
3）开发团队是否坚持了已经指定的编码标准-通过代码风格检查
4）自动测试覆盖了多少代码-通过测试覆盖工具，目前这块好像比较少
5）在最后一次变更之后，是否成功了通过了所有的测试br> 6）应用程序是否已经满足性能需求br> 7）最近的开发是否存在问题br>
以上没有注释的几点，个人认为必须将持续集成和后面的测试结合起来才能体现和回答这些问题。
关于测试环境，生产环境，开发环境和持续集成之间的关联

就重要性而言，生产环境应该是最为严格和优先级最高的，开发环境相对轻松，测试环境处于中间。那么如果和持续集成对应起来，开发环境应该是针对开发，更多的面向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中非常重要的一部分。