1. 概述

Travis CI提供的是持续集成的服务。它绑定GitHub上的项目，只要代码有变更，就自动运行构建和测试，反馈运行结果。确保符合预期以后，再将新代码“集成”到主干。它的好处是，能够快速发现错误，防止分支大篇幅偏离主干。而实现这方式的核心措施是：代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

Travis CI只支持GitHub，不支持其他代码托管服务。

2. 使用Travis CI

1. 使用准备

2. 使用流程

3. 配置文件.travis.yml

Travis要求项目底下存在.travis.yml配置文件，它描述了Travis的行为。该文件需保持在GitHub仓库，当代码存在新的commit，Travis将查找此配置文件，并执行其中的命令。

以下我们以Node项目为例，说明下配置。

language: node_js  // 指定运行环境
sudo:false      // 是否需要sudo权限
node_js:      // 指定node版本，值还可为：node：最新稳定的Node.js版本；lts/*： 最新的LTS Node.js版本
  - "8"     
  - "10"

1. install 字段

用于指定安装脚本

// 安装单个脚本
install: ./install-dependencies.sh

// 安装多个脚本，但若command1失败了，整个构建就停止，不再往下进行
install:
 	- command1
	- command2

// 不需要安装，即跳过安装
install:true

2. script字段：

指定构建或测试脚本

// 执行单个脚本
script: command1

// 执行多个脚本，若command1失败，command2仍会执行，但整个构建阶段是失败的
script:
	- command1
	- command2

// 命令先后执行,command2只能在command1执行后执行
script: command1 && command2

在Node项目中，install的默认值是：，script的默认值是：。但是如果package.json根文件夹中没有文件，则默认的构建脚本为：。下面区别下这俩指令的执行。

3.

命令执行时，会执行package.json的配置的指令，此方式常见，不详述。如下：

{
	"scripts":{
  	"test":" "test": "node ./node_modules/tad/bin/tad" // 执行特定的测试脚本
  }		
}

4. make test

：make是一个根据指定的Shell命令进行构建的工具。它的构建规则都写在Makefile文件里。

4. 集成案例

这里我们以测试isarray为例，说明下。

.travis.yml  // travis配置文件
index.js // 项目代码入口文件
Makefile  // make命令的构建规则文件
test.js  // 构建测试脚本
package.json // 此处的scripts没有配置test命令脚本

language: node_js
node_js:
  - "0.8"
  - "0.10"

// test.js 文件
var isArray = require('./');
var test = require('tape');

test('is array', function(t){
  t.ok(isArray([]));
  t.notOk(isArray({}));
  t.notOk(isArray(null));
  t.notOk(isArray(false));

  var obj = {};
  obj[0] = true;
  t.notOk(isArray(obj));

  var arr = [];
  arr.foo = 'bar';
  t.ok(isArray(arr));

  t.end();
});

test:
	@node_modules/.bin/tape test.js  // 描述执行测试文件
.PHONY: test

假设

5. 部署

script阶段结束后，可以设置通知步骤（notification）和部署步骤（deployment）。部署的脚本可以在script阶段执行，也可以使用Travis提供的几十种常见部署服务。这里以部署到Github Pages为例子：

访问令牌的作用是：授权仓库操作权限。

点击【Generate new token】则进入创建新token，部分配置截图如下：

配置的环境变量可以直接在配置文件中访问到。如若配置私密的环境变量，则一定要加密，因为会在日志中显示出来，被他人看到。

// 部署到github
deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GH_TOKEN  // travis.org面板配置的变量
  on:
    branch: master
// 通知
notifications: 
  email:
    - ***@**.com  // 通知邮箱
 /** 
 	*  [更多的配置信息]
 	*
local_dir：要推送到GitHub Pages的目录，默认为当前目录。可以指定为当前目录的绝对路径或相对路径。
repo：仓库回购，默认为当前仓库。注意： slug由用户名和仓库名称组成，格式如user/repo-name。
target_branch：分支到（强制，请参阅keep_history：）将local_dir 内容推送到，默认为gh-pages。
keep_history：可选，创建增量提交而不是执行推力，默认为false。
fqdn：可选，为您的网站设置自定义域，默认为不支持自定义域。
project_name：默认为fqdn用于元数据的值或存储段值。
email：可选，提交者信息，默认为deploy@travis-ci.org。
name：可选，提交者，默认为Deployment Bot。
committer_from_gh：可选，默认为false。允许您使用令牌的所有者名称和电子邮件进行提交。替代email和name选项。
allow_empty_commit：可选，默认为false。如果启用仅 keep_history是true。
github_url：可选，自托管的GitHub企业的网址默认为github.com。
verbose：可选，请在内部步骤中详细说明，默认为false。
deployment_file：可选，默认为false，启用创建部署信息文件。
*/

本地修改完成，并提交push到github仓库，就可以在travis-ci.org中看到项目开始构建了，且之后的每次推送代码到仓库后都将会自动构建项目。

6. 总结

通过相关知识点的学习，我们已经能够实现一个最简单的持续集成服务，从搭建到测试，到部署。