持续集成

代码不是技术团队的交付物，可运行的软件才是
虽然我们在同一个时代写代码做开发，但技术实践层面，不同的团队却仿佛生活在不同的年代。



把开发工作流程分为以下几个阶段：
编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署
「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」有着不同的软件自动化交付周期。

概念

持续 (Continuous)：不断的获取反馈，响应反馈。
集成 (Integration)：当我们在一个团队中工作的时候。把不同人的代码放在一起，使之成为一个可工作软件的过程叫集成。编译、测试、打包；
部署 (Deployment)：应用组件或基本设施的代码或配置变更在产品环境生效称为“部署”；
发布 (Release)：具有业务影响的功能变化对最终用户可见称为“发布”。
交付 (Delivery)：可以理解为从 Deployment 到 Release之间的阶段，更多的强调的是一种能力。开发有能力频繁的部署，业务有能力随时发布。

目的

名词说的那么多，扯的天花乱坠也没什么卵用，达到实际的效果才行。没有标准都是纸上谈兵
原则：开发人员提交代码到git，剩下的事情软件自动完成，打开浏览器可以直接看到程序界面
让产品快速可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。
只要有一个测试用例失败，就不能集成。
"持续集成并不能消除bug，而是让它们非常容易发现和改正。"

条件

• 全面的自动化测试：这是实践持续集成&持续部署基础，同时，选择合适的自动化测试工具也极其重要；
• 灵活的基础设施：容器，虚拟机存在让开发人员和QA人员不必再大费周折；
• 版本控制工具：如Git、SVN
• 自动化构建和软件发布流程工具：如Jenkins
• 反馈机制：如构建/测试失败，可以快速反馈到相关负责人，以尽快解决达到一个稳定的版本。

优点

• "快速失败"，对产品没有风险情况下进行测试，并快速响应
• 最大限度减少风险，降低错误代码修复的成本；
• 将重复性的手工流程自动化，让工程师更加专注代码；
• 保持频繁部署，快速生成可部署软件；
• 提高项目的能见度，方便团队成员了解项目的进度和成熟度
• 增强开发人员对软件产品的信心，帮助建立更好工程师文化
• 快速发现错误。没完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易
• 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度很大，甚至难以集成

选型

选择合适的集成系统，私有部署还是托管型持续集成系统。
条件：
团队运行的基础设施
集成系统资源投入力度
Maven、Gradle或Jenkins，他们的特点是自由开源，且文档支持广泛。优点在于构建环境有完全的控制权，
能够实现完全的定制。但需要搭建环境和配置、维护成本高，需要买专门的机器，话费较多的人力物力且更新迁移
更新高；

• CircleCI：https://circleci.com/
• Codeship： https://www.cloudbees.com/products/codeship
• TravisCI ：https://travis-ci.org/
• FlowCI：https://github.com/FlowCI/docs，https://flowci.github.io/#download

整体而言，目前大部分公司选择的是Jenkins，随着云服务，Docker，Saas的普及，越来越多的企业选择托管型集成系统。
选择持续集成系统只是持续集成应用的其中一步，还需要建立合适的集成文化比如代码质量管控、测试文化。做好持续集成，可为持续交付与持续部署打好坚实基础。

流程

** 迈向持续集成**

1. Daily Build 每日构建
   
   
2. 开发与集成合二为一
3. 尽早提交代码去集成
   1. 尽早把代码和已有代码集成到一起，而不应该等着所有代码都开发完了，再去做提交
   2. 通过尽早集成。减少改动量，降低集成难度
4. 执行同样的操作，本地环境会快于CI服务器环境
   
5. 只有CI服务器处于绿色的状态才能提交代码，用好本地构建脚本（build script），保证各种各样的检查都可以在本地环境执行
   
   
   

1.提交

流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交.

2.测试（第一轮）

代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。

• 单元测试：针对函数或模块的测试
• 集成测试：针对整个产品某个功能

3.构建

通过第一轮测试，代码可以合并进主干，就算可以交付了
交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源代码转换成可运行的实际代码，比如安装依赖，配合各种资源（样式、JS脚本、图片）等等。
常用的构建工具：

• Jenkins
• Travis
• Codeship
• Strider

Jenkins宇Strider是开源软件，Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。

4.测试（第二轮）

构建完成，就要进行第二轮测试。如果第一轮已经覆盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。
第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端到端的测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑
需要强调的是，新版本的每一个更新点都必须要测试到。如果测试的覆盖率不高，进入后面的部署阶段，很可能出现严重的问题。

5.部署

通过了第二轮测试，当前代码就是一个可以直接部署的版本。将这个版本的所有文件打包存档，发到生产服务器。
生产服务器将打包文件，解包成本地的一个目录，在将运行路径的符号链接指向目录，然后重新启动应用。这方面的部署工具有Ansible，Chef，Puppet等。

6.回滚

一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本目录。