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

软件开发需要避免的问题：假定。其实工作中也一样，不要想当然，一定要找到证据说话！！！证据才能说明一切，在寻找证据的过程中你需要假定，但不要什么都想当然。

减少假定：持续集成在每次版本控制系统发生变更时就执行构建，这有助于减少项目中的假定。

CI作为品质的中心工作：
CI不是不重要的工作，也不是杂活，书中提出一个观点，把CI看做是软件开发的中心工作，通过它对每次变更进行构建保证了软件的健康。

说一说我对这个的体会，最开始接触CI我是挺瞧不起的，因为觉得这完全就是打杂的工作，在一个软件开发的流程中，测试开发甚至需求分析都不沾边，只是在做着一个环节无关轻重的东西。但随着工作的深入，特别是到CI出了问题，有其是在产品需要GA自己，build出不来之后，所有的开发经理，测试经理，release mamanger都会跳出来讨论， build的同事也会成为一线挡在前面的人，那个时候便会深刻的体会CI在产品开发的环节中是如此重要。

CI的价值：
减少风险
减少重复过程
在任何时间任何地点生成可部署的软件
增强项目的可见性
对开发团队的软件产品建立起更强大的产品信心

我来谈一下这个看法：在国内很多的公司，特别是产品规模不够的情况下，很多人包括管理层都不能意识到CI带来的好处，他们觉得CI浪费时间，是个形式主义，会无形中给开发人员带来较多的麻烦，比如在实践过程中可能需要频繁的check in code等，甚至还有的说CI就是用来做自动化测试的。不得不多这是对CI的理解上的偏差。很多人羡慕大公司工作氛围相对轻松，不要经常加班加点等，这当然有文化的氛围在里面，但有没有考虑过一个问题？他们的项目管理做得更标准，更流程化更为严格。在大型软件开发项目中，如IBM，CI是个很重要的组成部分，甚至有专门的团队来从事这项工作，如果CI真的是形式主义，难不成这些软件大佬脑子进水了？我对CI作用的理解是：减少风险，提高软件进度的可见性，任何时刻软件都是可部署的集成的制品，可能离产品还有一定差距，但起码能够集成，各个component能够工作，这会增强开发团队对软件产品的信心，也让release manager和PM对产品有更大的信息。

减少风险：
缺陷的检测和修复变得更快：CI每天进行多次集成并执行测试盒审查，缺陷能够更早被发现
软件的健康程度可以测量：
减少假定：通过在一个干净的环境中不断使用相同的过程和脚本重复构建和测试软件，可以减少一些假设，如第三方库依赖，环境变量等。
对于这一点大家想必不陌生：一个最经典的听到最多的话可能是：在我的环境中是好的

什么阻碍了团队使用CI：
增加了维护CI系统的开销
变化太大
失败的构建太多
额外的硬件、软件成本
开发者应该执行这些动作

I Build So Consistently: IBSC 对应于identify 确定，Build 构建，Share 分享和Contunuous 持续

持续集成和持续编译的不同：

CI不仅仅是一种技术上的实现，它还是一种组织和文化上的实现，一般在项目初期就要引入CI比较好。

CI的7大最佳实践：

1. 经常提交代码：有几点需要强调：进行小的变更和在每个任务之后进行提交，要避免让所有的人在每天同一时间提交代码
2. 不要提交无法构建的代码：通过执行私有构建来解决
3. 立即修复无法集成的构建
4. 编写自动化的开发者测试
5. 必须通过所有测试盒审查
6. 执行私有构建
7. 避免签出无法构建的代码：在上一个的构建错误未解决之前，不要盲目的签出代码。