原文链接 http://veryyoung.me/blog/2016/11/20/continuous-integration-reading-note.html
注：以下为加速网络访问所做的原文缓存，经过重新格式化，可能存在格式方面的问题，或偶有遗漏信息，请以原文为准。
最近工作很忙，利用休息时间花了接近一个月时间才读完《持续集成》和《持续交付》。
读完有一定的感触，写篇文章记录下吧。
<!-- more -->
什么是持续集成？
持续集成是一种开发实践，即团队的成员经常集成他们的工作，每次集成都通过自动化的构建（包括编译、自动化测试、发布）来验证，从而尽快地检测出集成错误。
持续集成的好处
减少风险
利用 CI，问题会在编译、自动化测试，甚至 staging 环境部署中就暴露出来，而无需冒着上线酿成大错的风险。
减少重复过程
通过自动化的 CI，可以让代码编译、数据库的集成、测试、审查、部署、反馈等重复的过程每次都以相同的过程执行，标准化，无需人工操作。
生成可部署的软件
CI 可以让你在任何时间发布可部署的软件，只要 CI 流水线保持全“绿”，你可以随时随刻发布软件。可部署的软件对客户或者老板来说，是最实际的资产了。
增强项目的可见性
CI 能让我们注意到趋势并进行有效的决策。比如利用 CI，我们可以即时的得到当前的构建状态和品质指标反馈等。
建立起更强大的产品信心
有效的 CI 能随着每一次“绿色”的构建，给产品开发人员带来极大的信心增强。团队人员能知道代码满足了规范标准，能按照预期运行，能马上发布。
持续集成的流程
下图是 CI 的大概流程
- 持续集成服务器不断从版本控制服务器上检查代码状态，看代码是否有更新
- 如果发现代码有最新的提交，那么就从版本控制服务器下载最新的代码
- 等代码完全更新以后，调用自动化编译脚本，进行代码编译、运行所有的自动化测试、进行代码分析、产生可执行的软件、部署软件等过程
- 如果构建失败了，及时的反馈给开发者
CI 对团队的要求
1. 经常提交代码
CI 的中心原则是“早集成，常集成”。开发者必须经常提交代码才能体现出 CI 的好处。如果没法做到经常提交代码，请尝试把任务拆解成一个个能在几小时完成并 验收的子任务，编写源代码和测试，在本地执行构建，构建成功再提交代码。
2. 不要提交无法构建的代码
提交无法构建的代码会阻碍团队其他人进行构建和提交，甚至会影响到软件的自动化测试和发布。
3. 立即修复无法构建的代码
无法集成的构建是没有能够报告成功的构建，可能是存在编译错误，测试或审查失败，数据库问题或部署失败。 在CI的环境下，这些问题必须立即修复，不然 CI 在 down 掉这段时间就没法进行下去了。
4. 编写自动化测试
为了在 CI 系统中运行测试，所有测试都必须自动化，可以使用 JUnit 这样的测试框架。
5. 必须通过所有测试和审查
测试和审查必须 100% 通过，构建才算成功，不然软件质量没法保证，集成的好处也没了。
6. 执行私有构建
为了确保代码提交能通过构建，请先在本地执行私有构建在提交代码。
7. 避免签出无法构建的代码
当遇到集成构建失败时，不要从版本控制库中切出新的代码。不然，本地没法执行，你必须花时间找到一些方法来绕过让构建失败的那些错误，才能编译和测试您的代码。
持续集成的要素
1.统一的代码库
所谓统一代码库就是工程师都在同一份代码上工作，也就是提倡主干开发模式。如果基于分支进行开发，代码只有在上线前 merge 到主干的时候才能开始集成， 那持续集成的效果都没了，而且在上线前 merge 代码简直是灾难。
采用分支开发模式的目的是为了规避代码 merge 的风险，为了避免自己不能上线的代码被顺带上线，这些都有办法解决的。
怕 merge 代码，就经常 merge，基于主干开发，每次 pull 都 merge，最怕的事情经常做，就不那么怕啦。
怕把不能上线的代码顺带上线，要想想代码为啥不能上线呢？是不是可以通过把任务切分成可验收的小任务，完成了就能上线，或者隐藏起来，不让普通用户发现就行？
2.自动构建和自动测试
为了确保持续集成能“持续”下去，构建和测试需要是自动化执行的，不需要人工触发。
3.每个人每天都要向代码库主干提交代码
每个人的工作要及时在持续集成工具上集成一遍，可以快速发现潜在的问题，快速验收开发成果，也方便掌控项目进度。
4.每次代码递交后都会在持续集成服务器上触发一次构建
开发人员的每一次提交都会在持续集成服务器上进行集成和测试，这样就保证开发人员从版本库中获取到的版本完全可以在本地的机器上面可以顺利编译。
5.保证快速构建
如果构建太慢，开发人员的很多时间会花在等待构建结果这件事情上。
6.模拟生产环境的自动测试
7.每个人都可以很容易的获取最新可执行的应用程序
8.每个人都清楚正在发生的状况
9.自动化的部署
能自动化地把软件成果部署在线上（自动上线叫做“持续部署”）或者 staging 环境，进行预览和 UAT 验收。
Others
自动化数据库集成
数据库的变更也应包含在持续集成的过程中，比如可以利用 flyway 这样的 db migration 工具。
持续审查
在构建中需要评估软件质量，比如代码风格是否满足要求，是否满足编码规范，测试覆盖率是多少。
可以利用 checkstyle、pmd、findbugs 等工具，在 ci 上可以利用 sonar 来跑这些东东。
持续反馈
如果构建失败，一定要及时反馈给开发者，便于开发者及时作出反馈。
最简单的反馈方式有 email，也可以利用闲置的显示器来建设团队的 ci monitor。