持续集成扫盲篇
一.基础概念
1.持续基本Continuous integration (CI)
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，
也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译发布自动化测试）来验证，
从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
持续集成强调开发人员提交了新代码之后，立刻进行构建、测试。根据测试结果，我们可以确定新代码和原有代码能否正确集成在一起
2.持续集成的好处主要有两个
- 快速发现错误，每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易
- 防止分支大幅偏离主干，如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
3.持续集成的目的
- 可以让产品快速迭代，同时还能保证高质量，它的核心措施是代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败就不能集成。
- 持续集成并不能消除bug，而是让他非常容易的发现和改正。
二.持续交付
1.持续交付Continus delivery (CD)
持续交付指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段
持续交付可以看作持续集成的下一步，他强调的是，不管怎么更新，软件是随时随地可以交付的
三.持续部署
1.持续部署 continuous deployment(CD)
持续部署是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境
持续部署的目标是，代码在任何时候都是可部署的，可以进入到生产阶段，前提是能自动化完成测试构建部署等步骤。
四.持续集成的一般流程
1.根据持续集成的设计，代码从提交到生产，整个过程有以下几步：
- 提交：流程第一步，是开发者向代码仓库提交代码，所有后面的步骤都始于本地代码的一次提交
- 测试(第一轮)：代码仓库对commit操作配置了钩子（hook）,只要提交代码或者合并进主干，就会跑自动化测试
- 构建：通过第一轮测试，代码就可以合并进主干就算交付了，交付后就进行构建，进入第二轮测试，所谓构建指的是将源码转换为可以运行的实际代码，比如安装依赖配置各种资源等
- 测试（第二轮）:构建完成，就要进行第二轮测试，如果第一轮已经涵盖了所有测试内容，第二轮忽略。
- 部署：通过第二轮测试代码就是一个可以直接部署的版本，将这个版本所有文件打包发到生产服务器
- 回滚：一旦当前版本有问题，就回滚到上一个版本的构建结果.
