CI-持续集成（1）-软件工业“流水线”概述

持续集成（Continuous integration）是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误 [1]。

持续集成 相当于将传统工业的 流水线 作业的思想应用到现代的 软件工业 中来。不同之处在于，工业流水线 最终出来的是一个一个的产品复制体，但是 软件流水线 最终出来的是一代一代更新迭代的版本，但是共同点在于：整体产出的效率将极大地增加。

首先说CI解决了的问题：

• 小步伐的产品迭代
• 高频率的版本发布
• 随时随地的系统集成
• 稳定的系统演进线路图

这些都是 现代敏捷软件工程 理论中所要求达到的目标。

传统开发协作模式的各种角色：

• 开发人员

  • 从事软件产品的功能开发
  • 编写单元测试脚本
  • 简单的开发阶段的功能验证

• 测试人员

  • 编写测试用例
  • 集成阶段全面的功能验证
  • 使用开发人员的交付物搭建测试环境
  • 进行功能测试
  • 一些自动化测试

• 发布人员

  • 维护发布的相关配置
  • 将通过测试的软件交付物按照流程发布到服务器上

• 运维人员

  • 监控并保持服务器上的服务 7*24h 正常运行

而且在传统的过程中，存在如下特点：

• 除了开发人员外，其它角色基本上是 全手工 或者 大部分手工，事务处理效率低
• 开发和交流基本靠 口口相传 或者 邮件/QQ，沟通成本大
• 大部分从业人员总是做重复枯燥的工作，没有技术成长性
• 实践活动缺乏积累性，每次都是从头开始的相同的人工重复

而 持续集成 的工程思想引进之后，会发生如下变化：

• 开发人员

  • 编写开发相关代码

• 测试人员

  • 设计自动化测试用例
  • 编写自动化测试相关代码

• 发布人员

  • 设置自动化发布方案
  • 编写自动化发布相关代码

• 运维人员

  • 设置自动化运维方案
  • 编写自动化运维相关代码

也就是说，所有的角色都要先是一个 开发人员 然后才是一个 XX领域人员。这种模式在目前IT智力密集的互联网行业特别明显，在一些主要的在线招聘平台里面可以看到大的互联网公司的招聘信息基本都是：

• 测试开发工程师
• 发布开发工程师
• 运维开发工程师

然后给的薪水待遇都是开发人员的待遇，甚至目前很多公司的岗位编制都是属于开发人员之列了。

在互联网行业里面，软件开发模式已经从 传统软件工程 向 敏捷软件工程 变迁，实现此思想的相应的方法也变迁，那么相应的从业人员的技能要求也要变迁。

换句话来说：IT行业的领域岗位，必须要掌握开发技能，如果不做出一些改变和提升，那么接下来的现象就是开发人员全线开始占领IT领域类的岗位了。

持续集成的典型的工具就是开源系统 Jenkins。通过对 Jenkins 工具的应用的研究，绘制了一个全流水线的软件开发图，如下：

前期 CI 环境准备：

1. 开发人员都开发好相应的代码

   • 功能开发人员开发好产品特性代码
   • 发布人员开发好自动化构建和发布代码
   • 测试人员开发好自动化测试代码

2. 使用 Jenkins 工具将这些工具链都组合起来

3. 将流水线调试成功，所有环境搭建好

以上相当于是CI体系的建立阶段，是会有一定的技术力量投入，但是后面的反复迭代过程，则是来收回这些成本的。

后期迭代工作流：

1. 开发人员向git服务器指定分支提交了新的代码

2. git服务器的 webhook 接收到提交事件后向 Jenkins 服务器指定接口发起请求，执行构建脚本

3. Jenkins 服务器顺序执行构建脚本

   • 从git服务器上面同步代码
   • 执行自动构建脚本，生成交付物
   • 自动搭建测试环境

4. Jenkins 执行自动化测试脚本

5. Jenkins 向 自动化发布 系统发起请求

6. 自动化发布系统 进行自动灰度发布

7. 触发 自动化测试系统

8. 逐步全网发布

基本上，如上步骤可以全自动化无人值守完成。整个过程高效且不容易出错，对比手工式的生产模式，持续集成手段将极大地减少每次迭代的周期，保证整体项目可以按照极小的步伐和极高的频率进行稳步演进。

此文作为 持续集成 系列文章的开端，还有一些偏重于理论部分，以让大家对整体架构有所了解，同时也建立起现代的软件工程的整体观念。

后续的部分将侧重于环境搭建及相应的环境代码的开发的介绍，最后能够形成一套完整的能够提供生产力的 持续集成 系统。