前言

如果你手动部署过项目，一定会深感持续集成的必要性，因为手动部署实在又繁琐又耗时，虽然部署流程基本固定，依然容易出错。

如果你很熟悉持续集成，一定会同意这样的观点：“使用它已经成为一种标配”。

什么是持续集成
Continuous Integration(CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
———ThoughtWorks
翻译过来就是：持续集成是一个开发行为，它要求开发者每天多次将代码集成到一个共享的仓库，每次提交都会被自动构建所检查，团队可因此提前检测出问题。

持续集成的工具非常多，例如用 java 语言开发的 Jenkins，由于其可以在多台机器上进行分布式地构建和负载测试的特性，很多大公司都在使用它。

但是 Jenkins 的不加修饰的界面界面让我有些嫌弃 …

随着 GitHub 的发展，出现了越来越多支持 GitHub 的 CI/CD 产品。在 GitHub 市场上，可以看到，已经支持的持续集成服务提供商已超过 300 多家（详情）。

选择 Travis CI，是因为身边很多朋友的推荐。

下面分享一下我是如何利用 Travis CI+GitHub 实现持续集成和自动部署的，通过我的一些研究和实战经验，希望可以帮到有需要的朋友。

什么是 Travis CI

Travis CI 是用 Ruby 语言开发的一个开源的分布式持续集成服务，用于自动构建和测试在 GitHub 托管的项目。支持包括 Javascript、Node.js、Ruby 等 20 多种程序语言。对于开源项目免费提供 CI 服务。你也可以买他的收费版，享受更多的服务。

Travis CI 目前有两个官网，分别是 https://travis-ci.org 和 https://travis-ci.com。
https://travis-ci.org 是旧平台，已经逐渐往新平台 https://travis-ci.com 上迁移了。对于私有仓库的免费自动构建，Travis CI 在新平台上给予了支持。

一、获取 GitHub Access Token

Travis CI 在自动部署的时候，需要 push 内容到仓库的某个分支，而访问 GitHub 仓库需要用户授权，授权方式就是用户提供 Access Token 给 Travis CI。

获取 token 的位置：GitHub->Settings->Developer Settings->Personal access tokens。

勾选 repo 下的所有项，以及 user 下的 user:email 后，生成一个 token，复制 token 值。

注意：这个 token 只有现在可以看到，再次进入就看不到了，而且是再也看不到了，忘记了就只能重新生成了，所以要记住保管好。

二、使用 GitHub 账号登录 Travis

进入 Travis 官网，用 GitHub 账号登录。（我目前使用的是它的旧平台）

登录后，会在 Travis 里看到自己 GitHub 账号下所有的 public open source repo。

三、开启对项目的监控

选择目标项目，打开右侧开关。

四、配置 travis

• 点击开关右侧 Settings，进入该项目的 travis 配置页
• 勾选触发条件
  
• 设置全局变量
  
  注意：第一步获取的 access token，必须设置
  设置好的变量可以在配置文件中以 ${变量名}来引用。
  

五、在项目根目录添加 .travis.yml 配置文件

注意文件名以 . 开头。

Travis CI 的一次构建分两个步骤：

1. install 安装，安装任何所需的依赖
2. script 脚本，运行构建脚本

Travis CI 提供了一些构建生命周期的“钩子”

一个完整的 Travis CI 构建生命周期：

1. OPTIONAL Install apt addons
2. OPTIONAL Install cache components
3. before_install
4. install
5. before_script
6. script
7. OPTIONAL before_cache(for cleaning up cache)
8. after_success or after_failure
9. OPTIONAL before_deploy
10. OPTIONAL deploy
11. OPTIONAL after_deploy
12. after_script

在 before_install、before_script之前，或者 after_script 之后，都可以运行自定义命令，详细资料可参考官方文档：Job Lifecycle

我在 footprint 项目中的 .travis.yml 完整配置：

language: node_js #设置语言

node_js: "10.16.3" #设置语言版本

cache:
  directories:
    - node_modules #缓存依赖

# S: Build Lifecycle
install:
  - npm i

script:
  - npm run build

#after_script 前 5 句是把部署分支的.git 文件夹保护起来，用于保留历史部署的 commit 日志，否则部署分支永远只有一条 commit 记录。#命令里面的变量都是在 Travis CI 里配置过的。after_script:
  - git clone https://${GH_REF} .temp
  - cd .temp
  - git checkout gh-pages
  - cd ../
  - mv .temp/.git dist
  - cd dist
  - git config user.name "${U_NAME}"
  - git config user.email "${U_EMAIL}"
  - git add .
  - git commit -m ":construction_worker:- Build & Deploy by Travis CI"
  - git push --force --quiet "https://${Travis_Token}@${GH_REF}" gh-pages:${D_BRANCH}
# E: Build LifeCycle

# 只有指定的分支提交时才会运行脚本
branches:
  only:
    - master

Done！

将 .travis.yml push 到远程，可以看到 travis 开始构建编译了。并且之后每次 push 代码，travis 都会自动执行 .travis.yml 里配置的脚本任务了。

• 自动编译：
  
• 构建完，travis 会根据我的配置，自动部署到 GitHub：
  

And One More Thing

构建成功后，我们就可以在自己的 GitHub 项目里添加 build 徽章了。
方法：在 Travis 里，点击项目右侧的徽章，即可获取小徽章地址，将地址放在 README.md 文档中即可。

效果：

—
GOODLUCK！

欢迎转载，转载请注明出处：https://champyin.com/2019/09/…

本文同步发表于：
利用 Travis CI+GitHub 实现持续集成和自动部署 | 掘金