持续集成 -- 理论篇
一、软件开发面临的问题
- 确定软件需求
- 确定项目进度（可见性）
- 如何以最快速度将软件交付给用户？
- 如何让开发、测试、产品经理、运维人员高效工作？
软件需要满足于业务目的，质量不等于完美，“追求完美是把事情做好的大敌”。
二、持续集成
持续集成是一种软件开发实践【不是工具】，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。 — Martin Fowler
持续集成
三、持续集成的价值
1.协作
让开发的软件一直处于可工作状态
2.开发人员
-
尽快发现问题
解决问题的关键是尽快发现问题
减少引入缺陷与修复缺陷之间的时间 -
防止分支大幅偏离主干
-
减少重复过程&人为错误：
以自动化编译、发布、测试...，代替手工操作
避免了一些人为的错误(build号忘加1、Debug开关忘关) -
建立团队对开发产品的信心
3. 测试人员
小步增量，易于发现问题，并快速反馈给开发人员
四、小结
集成的目的其实是沟通：集成可以让开发者告诉其他人他们都改了什么东西，频繁的沟通可以让开发者更快地了解变化。
五、持续集成的前提条件
1.团队共识
持续集成不是工具，是一种实践，需要投入并遵守一些规则，才能提高质量
2.频繁提交
“如果你遇到一件很痛苦的事情，似乎比较好的建议就是更频繁地做这件事情”
— Martin Fowler
哲学：一件事情很难，又必须去做，不妨经常去做，每次做一点，分而治之，滴水穿石、跬步千里 —— 早集成、常集成
解决问题的关键是尽早发现问题
每过几个小时就提交一次，冲突也会在几个小时之内被发现
两次提交之间只有几个小时的修改，产生这些问题只可能在很有限的几个地方
提交的越多，需要查找冲突错误的地方就越少，改起来也越快
用差异调试比较当前版本和之前没有 bug 的版本
客观上会鼓励开发者将工作分解成以小时计的小块
3. 保证每次提交的质量
每次提交的版本都有可能产生一个可发布的版本
每次提交的质量不好，不但会影响自己，而且会影响别人
4.不单单源代码
与项目相关的所有内容（代码、测试代码、数据库脚本、构建与部署脚本、 IDE配置文件，以及所有用于创建、安装、运行、测试应用程序的东西）
关于这点，可以参考持续集成之“Everything is code”
5. 全面的自动化构建、测试套件
- 10分钟 build（快速的build）
没有什么比缓慢的 build 更能危害持续集成活动
一旦提交 build 成功，其他人就可以放心地基于这些代码工作了 - 在不同的情况中 build 不同的 target
- 每次代码提交后都会在持续集成服务器上触发一次构建
构建不只是编译，可能包含编译、测试、审查和部署以及其他一些事情，将代码放在一起，并让其可以作为一个一致的单元运行的过程 - 自动化标准
任何人都应该能从一个干净的计算机上 check out 源代码，然后敲入一条命令，就可以得到能在这台机器上运行的系统
6. 本地环境与持续集成环境、测试环境、生产环境一致
deployment-plan.gif
关于环境可参考：Traditional Development/Integration/Staging/Production Practice for Software Development
六、必要的实践
1.“最新的正确版本”作为起点
2.时刻准备回滚到前一个版本
3.修复破坏应用程序的任意修改是最高优先级的任务
10分钟修复不完，需要回滚&在回滚之前要规定一个修复时间
4. 等提交测试通过后再继续工作
给自己喝一杯咖啡的时间
等待集成返回结果后继续工作能减少错误，也能让别人在最新的正确版本作为起点
5.提交前在本地运行所有的提交测试
现代CI服务器提供“预测试提交”、“个人构建”
6.构建失败后不要提交新代码
7.谁提交，谁负责
监视 mainline 上的构建，失败时及时修复
如果在下班前提交了代码，那在 mainline 构建成功之前就不能回家
8.勿将失败的测试注释掉
修改代码、修改测试、删除测试
9.测试驱动开发
七、 持续集成实践步骤
1.自动化构建
2.引入自动化测试
试着指出主要出错的地方，并要让自动化测试暴露这些错误
3.试着加快build 的速度
10分钟build
4.CI选型
5.寻找老司机帮忙（很重要）
老司机理论+实践经验丰富
