1 - 持续集成简介

持续集成（Continuous integration，简称CI）是软件的开发和发布标准流程中最重要的部分。
作为一种开发实践，在CI中可以通过自动化等手段高频率地去获取产品反馈并响应反馈的过程。
简单来说，就是持续不断地（一天多次）将代码合并（集成）到主干源码仓库，让产品可以快速迭代，同时保持高质量。

代码每次集成到主干之前，必须通过自动化测试，以便快速发现和定位错误。
持续集成并不能消除错误，而是让它们非常容易发现和改正。

1.1 适合使用持续集成实现自动化的工作类型

• 应用程序的静态测试（静态检查）：不用实际运行应用程序就可以进行的测试，例如语法错误和编码规范等
• 应用程序的构建：验证依赖关系等问题
• 应用程序的动态测试：单元测试和集成测试等

1.2 持续集成的优点

1. 缩减开发周期，快速迭代版本
   　尽早的持续集成，尽快进入迭代之中，就可以尽早的暴露出问题，提早解决，尽量在规定时间内完成任务。

2. 自动化流水线，削减工作成本
   CI的精髓在于持续，持续意味着自动化。
   自动化验证代码变更的过程，可以在软件开发的早期发现缺陷和与其他代码和组件的集成问题。

3. 随时可部署
   　高频率的集成可以尽可能地保证随时部署上线，缩短开发复杂软件的市场交付时间。

4. 极大程度避免低级错误
   　减少大块内容合并到主干分支的情况，避免代码合并冲突和无法预料的行为。
   　低级错误：编译错误，安装问题，接口问题，性能问题等。

5. 状态可视化，信息透明化
   　轻松快捷地确认更改信息、提交过程和测试结果，所有信息公开共享，利于协作

1.3 持续集成的难点

• 迁移遗留代码到现有CI系统，需要的投入通常在预料之外
• 在文化和组织上如果没有采用敏捷原则或DevOps的工作方式，那么很可能没有持续不断的提交，那么CI的存在意义不大
• 随着业务增长、工具的更替、技术的演进，CI系统也必然随之改动，往往会导致阶段性的不稳定和人力物力的耗费
• 如果CI的基本设定不到位，开发流程将会增加特别的开销

1.4 持续集成的注意点

工具

持续集成工具必须能够定义触发操作的时机、确认操作的状态、保存操作的记录。

代码仓库

对于持续集成来说，建议只维护一个源码仓库，对于新需求一般采取创建分支的方式，这也可以降低版本管理的复杂度。

CI流程的触发方式

• 跟踪触发式：在每次提交到源码版本管理系统时触发
• 计划任务：预配置好的计划，例如一次凌晨的构建
• 手动：无论是通过CI服务器的管理界面还是脚本，用户可以手工执行CI工作流

代码审核

• 可在持续集成服务器里使用代码分析工具（例如Sonar）来执行自动代码审查
• 自动代码审查通过后，可发起一个人工代码审查，揪出那些自动审查无法找出的问题，即验证业务需求，架构问题，代码是否可读，以及是否易于扩展。
• 可灵活配置代码审核策略，例如：如果某些人没有审查代码便阻止对主干分支的任何提交。
• 最常用的工具是Gerrit

1.4 实现持续集成的一些方法与途径

• 从操作步骤上，将多个处理关联起来实现自动化
• 通过自动化测试快速执行大量测试，尽量覆盖所有场景
• 基于时间或者提交进行细颗粒度测试
• 立即通知测试结果，例如直接显示、邮件通知、关联即时通讯工具等
• 避免测试等待，优化测试时间，例如分割测试用例、并行测试等
• 重复进行多种测试，为发布做好准备

2 - CI流程

从持续集成的组成部分来理解CI流程，其实就是将应用程序的开发与基础设施的构建流程合并起来，在一个流程内对二者进行测试。

2.1 典型的CI流程

一个完整的CI系统应该包含3个基本模块：

• 一个可以自动构建的过程，自动编译代码，可以自动分发，部署和测试。
• 一个代码仓库，例如Git。
• 一个持续集成的服务器。

2.2 通用的CI流程

1. 签出代码：
   从源码管理系统里签出或者克隆最新的代码到本地开发环境

2. 提交（commit）：
   基于主干分支创建一个新的功能分支，并在此分支编写代码，并向仓库提交代码

3. 测试（第1轮）：
   代码仓库对commit操作配置了钩子（hook）， 每一次提交代码都会触发测试
   单元测试（针对函数或模块的测试）和功能测试（集成测试）将会被执行、根据需要设置是否执行端对端测试
   一般来说，这些测试也会被打包到代码里。

4. 构建（build）：
   通过测试（第1轮）后，将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源等
   实现一个CI流程的唯一必要条件便是得有一个自动构建系统。
   源代码一般是自包含构建的，即CI流程所需的构建脚本是放在源码仓库里的。

5. 测试（第2轮）：
   以自动化为主的全面测试，包括单元测试和集成测试，必要时做端对端测试，确保新版本的每一个更新点都必须测试到

6. 合并：
   通过测试（第2轮）后，将代码更新集成到主干

7. 回滚：
   如果当前版本发生问题，就回滚到上一个版本的构建结果
   一般来说，CI服务器会配置成在遇到故障时发送邮件相关人员，可以快速知晓故障并且尽快采取更正措施。

2.3 实际使用场景中一次提交改动的过程

1. 团队成员提交改动
2. Gerrit做代码审核，提交到GitLab，并通过邮件通知相关人员
3. Sonar做代码扫描，并把结果通知相关人员
4. 在GitLab中打tag（通过WebHook触发Jenkins作业），或者手工触发Jenkins Job,
5. Maven开始下拉代码进行编译，然后进行单元测试和打包
6. 利用Docker cli构建镜像，并把镜像上传到镜像仓库中
7. Jenkins作业触发容器管理工具在测试环境中启动容器，下拉镜像，并根据配置启动容器
8. 容器管理工具自动或按规则调度容器运行，并负责容器声明周期管理（启动、运行、监控、健康检查、扩展等）
9. 进行自动化测试
10. 测试通过后，Jenkins触发容器管理工具在生产环境中更新测试通过的改动，或者选择手动发布

3 - CI与TDD结合

Continuous integration (CI) 与test-driven development (TDD)结合，分成了12个步骤：

4 - 参考消息

• 仅需一篇，妥妥吃透“持续集成”