webpack + Travis CI 自动部署项目应用

咱们知道 Github Pages 是 Github 免费提供给用户展现页面的一项服务。当咱们完成项目开发后，想将页面部署到 Github Pages 时，该要怎么操做呢？

能够在 GitHub 的储存库设置中设置用于展现页面的分支，该分支只保留构建后的静态资源，也就是源码与编译后的静态资源分离。按照传统的作法是：手动运行编译命令，编译后再复制到指定分支中。这样操做很繁琐，但使用 Travis CI 持续集成服务以后就能够不用操心这些事了。

概念

既然咱们要使用 Travis CI，首先得搞清楚人家具体是干吗的吧？

Travis CI 是一个 持续集成(Continuous integration, CI)。它与 git 相耦合，每当有 commit 提交时，它将自动触发构建与测试。若运行结果符合预期，才将新代码集成到 主流(mainline) 中，这样使应用更加健壮。

值得注意的是，Travis CI 提倡每次 commit 都是独立较小的改动，而不是忽然提交一大堆代码。由于这有助于后续构建失败时能够回退到正常的版本。

运行构建时，Travis CI 将 GitHub 存储库克隆到全新的虚拟环境中，并执行一系列任务来构建和测试代码。若是这些任务中的一项或多项失败，则将构建视为已损坏。若是全部任务均未失败，则认为构建已经过，Travis CI 会将代码部署到 Web 服务器或应用程序主机中(在本文中是指 Github Pages 服务)。

准备

在使用以前，须要准备一个 Github 的帐号对 Travis CI 进行受权。

1. 接着经过 Github 的帐号登陆 Travis CI，点击 SIGN IN WITH GITHUB。
2. 点击后会被重定向到 Github 进行受权。
   
3. 受权后，如果第一次登陆的话会被重定向至引导页:
   

4. 点击引导页第一步的按钮，使用 GitHub Apps 激活储存库。能够选择给所有储存库都激活，也能够激活指定储存库。本文以 <username>.github.io 为例:

   注意: 这个 username 是你本身的 Github 用户名。笔者的 username 为 anran758 那储存库的名字就为 anran758.github.io。

   

5. 激活后会被重定向到设置页，点击待部署的储存库右侧的 setting 按钮，跳转至 Travis CI 储存库设置页。咱们须要在此页设置部署 Github Pages 时所需的环境变量:
   

环境变量的值须要从 Github 拿拥有部署权限的 token:

1. 打开 Github，点击头像，再点击 Settings 进入设置页：
   
2. 进入设置页面后在左侧边栏点击开发者设置:
   
3. 跳转后在左侧边栏点击 Personal access tokens, 而后在头部点击 Generate new token:
   
4. 填写 token 备注、权限，最后点击生成 token:
   
5. 生成 token 后点击复制按钮，复制到粘贴板:
   
   注意要妥善保管好 token，从新刷新页面后这个 token 将不会再展现出来。若是忘记了 token 的话，也只能在 token 编辑页中从新生成。这会致使全部用到该 token 的应用都要更新值。 比方说有三个应用使用了该 token，从新生成后只在一个应用更新的值，那其余两个应用不更新就没法使用了。
   
6. 复制 token 后切回 Travis CI 储存库的设置页，添加环境变量:
   

这样咱们的准备工做就完成的差很少了。

配置

在项目目录中新建文件 .travis.yml，内容以下:

language: node_js
node_js:
  - lts/*

install:
  - yarn install # npm ci
script:
  - yarn test # npm run test
  - yarn build # npm run build

deploy:
  provider: pages
  local_dir: dist
  target_branch: master
  on:
    branch: develop
  token: $GITHUB_TOKEN
  skip_cleanup: true
  keep_history: true
  committer_from_gh: true

因为 webpack 项目依赖 Node.js，所以语言(language) 设置为 node_js，同时还指定使用最新的 LTS Node.js 版本(lts/*)。

install 是安装部署所需的依赖项，script 则是用于运行测试或构建脚本。他们都是 Travis 的工做生命周期(Job Lifecycle)必触发的钩子(阶段)。

install 钩子如有脚本/命令运行失败的话，整个构建会中止。而 script 钩子表现则不一样，当有脚本/命令运行失败后虽然构建会失败，但还会继续执行后面的脚本。如 yarn test 运行失败后会继续跑 yarn build 命令。

如下是 Travis CI 主要的阶段流程图:

部署

经过 deploy 能够指定部署方式，下面将逐个介绍部署所用的选项：

provider 是部署类型。如今咱们想将页面部署到 Github Pages，那就须要将 provider 设为 pages。

local_dir 指定要推送到 Github Pages 的目录，默认为当前目录。webpack 默认的输出目录是 /dist，所以须要将值设为 dist。除此以外，Travis CI 默认状况下会删除构建期间建立的全部文件，所以须要设置 skip_cleanup: true 保留构建出来的 dist 目录.

若 on.branch 有 commit 提交的话，Travis CI 将从 on.branch 分支运行编译脚本，编译后会把 local_dir 目录强制推送到 target_branch 中。(target_branch 默认值为 gh-pages)

如今咱们要部署的储存库是 <username>.github.io。这种类型的储存库有些特殊——它只能在 master 分支展现构建后的代码，而不能修改成其余分支。在 GitHub 储存库的 Settings 中的 Source 选项能够看到详细信息:

然而其余储存库则没有这种限制:

所以要部署到 <username>.github.io 储存库的话，target_branch 只能设为 master，触发编译的 on.branch 分支则能够本身定义。

其余储存库能够按照标准流程来开发：

• develop 做为开发分支
• master 做为主分支
• gh-pages 做为页面展现分支

等功能开发并测试完毕后，将 develop 的代码合并到 master 分支并推送至远程。Traivis CI 检测到 matser 有 commit 提交后会自动运行脚本构建，构建完毕后将输出目录推送至 gh-pages 分支。

固然 Github Pages 也不是随便来一我的就能够部署的，你想要部署到储存库中首先得有该储存库的操做权限吧？token 就是证实你身份的东西。在上文中咱们预先设置好了一个名为 GITHUB_TOKEN 的环境变量，此处咱们能够经过 $GITHUB_TOKEN 直接取出该环境变量的值便可。

其余还有一些细节问题能够调整：好比推送构建后的代码到 target_branch 时使用的是强制推送(git push --force)，若是你以为这种强制覆盖历史记录的方式有点暴力的话，能够设置 keep_history: true 来保留提交记录。

自动部署后 commit 提交者默认是 Travis CI 的信息。也能够设置 committer_from_gh 容许 Travs CI 使用令牌全部者的我的信息来提交 commit。

配置完毕后如今只需将 .travis.yml 提交到远程，Travis CI 就开始工做了：

甚至还能够在 Github commit 信息中看到编译的状况:

若是构建出问题的话，Travis CI 还会发邮件提示你:

部署成功后就能够直接经过浏览器访问啦~ 储存库部署的是 <username>.github.io 的话，访问连接为 https://<username>.github.io/。其余储存库能够访问 https://<username>.github.io/<repoName>。

好比笔者的主页与博客是两个项目分离的，部署后的连接地址为 https://anran758.github.io 和 https://anran758.github.io/blog。

参考资料:

• Creating a personal access token for the command line
• GitHub Pages Deployment
• Job Lifecycle

---

原文出自: webpack + Travis CI 自动部署项目应用