持续集成是什么

互联网软件的开发，已经成熟、标准化，其中最重要的组成部分就是持续集成（Continuous integration，简称CI）。

持续集成是一种软件开发实践，即团队开发成员常常集成它们的工做代码，每一个成员天天至少集成一次，也可能会发生屡次集成。每次集成都经过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成BUG，并解决。

简单说就是：

频繁地提交代码，集成进主干分支，及早发现问题，并解决。

举个例子：

1. 公司某项目在代码仓库存在三个分支：dev（开发分支）、master（主干分支）、release（预发布分支）
2. 开发组有两个以上的人员在分别开发A、B、C...等不一样的功能模块
3. 每一个开发人员完成自身某个功能模块的开发后，须要将本地检验合格的代码push到dev分支，
4. 代码仓库配置的webhooks会根据commit动做回调测试服务器，测试服务器对提交的代码进行单元测试
5. 单元测试经过，则集成进主干分支；不经过则不集成，并通知生成方完善处理
6. 集成进主干分支后，主干分支进行编译、构建（主要包含环境配置、安装依赖、资源整理）
7. 构建完成，进行集成测试（总体测试 [, 端对端测试]），测试经过则将主干分支合并至预发布分支（release）
8. 合并至预发布分支后，预发布分支根据实际需求选择是否直接实施部署
9. 若是部署，则部署服务器则会将最新预发布分支的代码，打包为当前版本，并推送至生产服务器
10. 生产服务器解压最新代码包至指定目录，修改程序的路径指向最新代码目录，并重载生产服务
11. 如若出现异常，生产服务器则直接将程序路径指向上一个版本的目录，进行回滚

如上所述，一个完整的持续集成流程至少须要包含：测试服务、部署服务、生产服务三部分；
单元测试、集成测试、功能测试这些自动化测试方法，是项目持续部署的基础，大部分测试都应该是自动化完成的，自动化测试覆盖不到的，应由人工测试；
而一切的一切都是从push代码那一刻开始。

如图：

持续集成最少能带来如下两点好处：

• 快速发现错误。每完成一点更新，就集成到主干，能够快速发现错误，定位错误也比较容易。
• 能帮助项目在短期内安全的发布新特性，而不用等上几个月甚至几年。

能够看出，持续集成的目的，就是让产品能够快速迭代，同时还能保持高质量。它的核心措施是，代码在进行下一步活动以前，必须经过自动化测试，只要有一个测试用例失败，就不能集成，从而保证软件质量，其也是TDD（测试驱动开发）的一个重要实践。

实际上，在生产环境里的 Bug 使你付出的代价每每要数倍于在自动化测试时发现的 Bug。
换句话说，若是你计算投资与回报的话，持续集成（TDD/测试驱动开发）将具备压倒性的优点。

下面咱们了解三个关于测试的概念：

单元测试

单元测试（unit testing），也叫模块测试，是指对软件中的最小可测试单元进行检查和验证，小到每一个变量、每一个函数、每一个类。

简单说：单元测试能够发现你编写的每一个函数、模块的错误，并输整理出。

以下测试用例：

describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      [1,2,3].indexOf(5).should.equal(-1);
      [1,2,3].indexOf(0).should.equal(-1);
    });
  });
});复制代码

使用工具执行该测试用例以后，其会输出正确率、错误率、错误节点及测试报表，从而判断咱们所编写程序的质量和错误，固然，实际测试的测试用例是须要引入并配置咱们的程序代码，执行测试的。

集成测试

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将全部模块按照设计要求组装成为子系统或系统，进行总体测试。

简单说：集成测试是把各个模块合并在一块儿，做为总体进行功能测试，发现错误，并输出。

软件开发的生命周期中，集成是必然的，具体的集成过程多是显性的也多是隐性的。只要有集成，老是会出现一些常见问题，工程实践中
，几乎不存在软件模块合并过程当中不出任何问题的状况。且集成测试须要花费的时间远远超过单元测试，但进行集成测试是极有必要的。

端对端测试

端对端测试，也叫交互测试，是软件被用于各类模拟真实使用场景中的测试，包含UI、交互、功能等各个方面。

在测试中，把程序看做一个不能打开的黑盒子，在彻底不考虑程序内部结构和内部特性的状况下，对程序测试，它只检查程序功能是否按照需求规格说明的规定正常使用，
程序是否能适当地接收输入数据而产生正确的输出信息。端对端测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

简单说：就是用工具来模拟人的真实操做，对软件进行测试，相似黑盒测试。

举个例子：咱们须要测试一款web产品，咱们须要知道在鼠标点击某个按钮时背景颜色发生了哪些变化，
跳转到了哪一个页面，是否弹出了预期的窗口，页面是否在预期的时间内加载到了完整的数据，在各类浏览器环境下的异常是否在预期范围内，
这些都属于端对端测试的部分。

说完了测试，咱们能够总结一下：

总体来讲，持续集成能够分为：持续交付（持续测试）、持续部署两个部分，对于开发人员来讲，最重要的就是交付（测试）部分。

在真实的生产实践中，咱们能够搭建本地的自动化测试+集成环境来提升效率。

如：咱们能够经过本地脚本，来实现咱们在输入project push那一刻，
程序开始进行代码检查、构建编译、单元测试、总体测试，测试经过后则自动提交，不经过则生成报表，继续优化Debug。

以上即对持续集成的理解和分享。

部份内容摘录自：阮一峰的博客

原文地址：surmon.me/article/17

完