1. 概述
Travis CI 提供的是持续集成的服务。它绑定 GitHub 上的项目，只要代码有变更，就自动运行构建和测试，反馈运行结果。确保符合预期以后，再将新代码“集成”到主干。它的好处是，能够快速发现错误，防止分支大篇幅偏离主干。而实现这方式的核心措施是：代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
Travis CI 只支持 GitHub，不支持其他代码托管服务。
2. 使用 Travis CI
1. 使用准备
拥有 GitHub 账号，没有就注册
该账号下面有一个项目
该项目里面有可运行的代码
该项目还包含构建或测试脚本
2. 使用流程
访问官方网站 travis-ci.org ，用 GitHub 账号登录，首次则授权登录
从 Travis CI 列出的 GitHub 仓库选择需要 Travis 帮助构建的仓库。一旦激活了一个仓库，则 Travis 会监听这个仓库的所有变化。
项目根目录增加.travis.yml 配置文件，当本地项目代码提交并 push 到 GitHub 仓库，则触发 Travis 构建。
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 的默认值是：npm install，script 的默认值是：npm test。但是如果 package.json 根文件夹中没有文件，则默认的构建脚本为：make test。下面区别下这俩指令的执行。
3. npm test
npm test命令执行时，会执行 package.json 的配置的指令，此方式常见，不详述。如下：
{ "scripts":{ "test":" "test": "node ./node_modules/tad/bin/tad" // 执行特定的测试脚本 } }
复制代码
4. make test
make test：make 是一个根据指定的 Shell 命令进行构建的工具。它的构建规则都写在 Makefile 文件里。
4. 集成案例
这里我们以测试 isarray 为例，说明下。
项目目录结构
.travis.yml // travis配置文件index.js // 项目代码入口文件Makefile // make命令的构建规则文件test.js // 构建测试脚本package.json // 此处的scripts没有配置test命令脚本
复制代码
编写.travis.yml
language: node_jsnode_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();});
复制代码
编写 Makefile 配置文件
test: @node_modules/.bin/tape test.js // 描述执行测试文件.PHONY: test
复制代码
假设
5. 部署
script 阶段结束后，可以设置通知步骤（notification）和部署步骤（deployment）。部署的脚本可以在 script 阶段执行，也可以使用 Travis 提供的几十种常见部署服务。这里以部署到 Github Pages 为例子：
从 GitHub 生成访问令牌
访问令牌的作用是：授权仓库操作权限。
点击【Generate new token】则进入创建新 token，部分配置截图如下：
travis 配置环境变量
配置的环境变量可以直接在配置文件中访问到。如若配置私密的环境变量，则一定要加密，因为会在日志中显示出来，被他人看到。
编写配置文件
// 部署到githubdeploy: 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. 总结
通过相关知识点的学习，我们已经能够实现一个最简单的持续集成服务，从搭建到测试，到部署。
评论