0202 年了，你还在手动部署前端项目吗？

导语

随着 Nodejs 的诞生，Nodejs的盛行给前端开发带来了更多的便捷，各种npm包，node工具。前端工程化进程也得到了极大推进，从项目创建、开发、到发布构建，都有一系列自动化流程。今天，我们就发布构建这个环节的自动化工作做讲解。

相关概念介绍

• 什么是CI/CD?
  通过持续集成，开发人员能够频繁地将其代码集成到公共代码仓库的主分支中。 开发人员能够在任何时候多次向仓库提交作品，而不是独立地开发每个功能模块并在开发周期结束时一一提交。
  
  
  CI 的目标是将集成简化成一个简单、易于重复的日常开发任务， 这样有助于降低总体的构建成本并在开发周期的早期发现缺陷。 要想有效地使用 CI 必须转变开发团队的习惯，要鼓励频繁迭代构建， 并且在发现 bug 的早期积极解决。
  
  持续交付（CD）实际上是 CI 的扩展，其中软件交付流程进一步自动化，以便随时轻松地部署到生成环境中。 成熟的持续交付方案也展示了一个始终可部署的代码库。使用 CD 后，软件发布将成为一个没有任何紧张感的例行事件。 开发团队可以在日常开发的任何时间进行产品级的发布，而不需要详细的发布方案或者特殊的后期测试。
  

  这个持续集成的过程就是上图的 deploy 过程。

• 前端项目持续集成的方案
  目前前端项目持续集成的工具有 Travis-CI、Github Actions、Gitlab Runner、CircleCI等等，前三个我自己都有用过，并且运行稳定。下面我将把一个github 私有仓库的前端代码自动构建到其他github公开库的 gitpage 页面为例，分别以 Travis-CI 和 Github Actions 来讲解。

• Travis-CI
  入口

Travis-ci 可以通过配置文件，提供一个虚拟环境，通过你的 github授权的token拉取远程仓库代码，然后打包编译，打包之后，还可以运行相应的脚本，推送到其他仓库或者其他远程服务中去，具体使用姿势请看travis-ci 使用文档

• 第一步，去你的github创建一个有拉取代码权限的 token，找到settings。
  
  找到developer settings
  
  找到 Personnal access tokens，创建一个 token
  
  每项具体是什么意思，自己可以去查阅，勾选越多，权限越大，安全隐患越高，一般来说，够用就行。按照项目需求，勾选如下两项即可。
  
  token 创建成功之后请妥善保存，只显示一次
  
  有了 token，我们就可以去 travis-ci 去设置了。
  第二部 找到 travis-ci 的 设置，配置环境变量
  
  
  以上变量在配置环境都用得到，具体配置文件是以.travis-ci.yml放在项目根目录的
  
  push代码的时候，具体自动触发 travis-ci 的自动构建过程了。
  下面是具体的配置文件内容

# 语言
language: node_js
# 版本
node_js: stable
# 依赖安装方式
# 安装命令
install:
  - yarn
 # 运行脚本
script: yarn build
# 脚本运行成功之后，运行多行脚本
after_script:
  - cd dist
  - cp index.html 404.html
  - echo "pro.abckey.com" > CNAME
  - git init
  - git config  user.name "${USER_NAME}"
  - git config  user.email "${USER_EMAIL}"
  - git add .
  - git commit -m "Automatically update from travis-ci"
  - git push --quiet --force  "https://${GH_TOKEN}@${GH_REF}" master:gh-pages
# 官方提供的 github-page 构建
deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GH_TOKEN
  keep_history: true
  on:
    branch: master
branches:
  only:
    - master

这样，我们的所有配置就完成了，就可以自己构建我们的项目了。自动构建时，我们可以看到整个构建过程，有错的话，也方便追溯错误。

构建成功后，我们去访问一下目的分支的 gh-page分支试试

看，已经构建成功啦！下面，我们再用 github actions 来实践一遍。

• Github Actions

除了 travis-ci，我们也可以用GitHub Actionss，GitHub Actions 是 GitHub 的持续集成服务，于2018年10月推出。阮一峰在博客也说道——觉得它非常强大，有创意，比 Travis CI 玩法更多。

我还是演示如何使用 GitHub Actions 自动发布一个 Vue 应用到 GitHub Pages。

• 一些术语：

（1）workflow （工作流程）：持续集成一次运行的过程，就是一个 workflow。

（2）job （任务）：一个 workflow 由一个或多个 jobs 构成，一次持续集成的运行，可以完成多个任务。

（3）step（步骤）：每个 job 由多个 step 构成，一步步完成。

（4）action （动作）：每个 step 可以依次执行一个或多个命令（action）

大家知道，持续集成由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。很多 Actions 已经被开发者写好了放在 了 github，我们可以直接用别人的就好了，如果不想自己写脚本的话。 GitHub 做了一个官方市场，可以搜索到他人提交的 actions。另外，还有一个 awesome actions 的仓库，也可以找到不少 action。

如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。

之前已经说了申请 token 的过程，这里就跳过了。action 也是直接以.yml的配置文件形式存在的，特别的地方是需要放在项目根目录下的.github文件夹下的 workflows文件夹里

因为引用了别人 actions，具体用去 github 参考别人的配置文档吧，配置内容如下：

name: GitHub Actions Build and Deploy Project
on:
  push:
    branches:
      - master
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@master

      - name: Build and Deploy
        uses: JamesIves/github-pages-deploy-action@master
        env:
          ACCESS_TOKEN: ${{ secrets.MY_DEPLOY_KEY }}
          BRANCH: gh-pages
          FOLDER: dist
          BUILD_SCRIPT: npm install && npm run build &&  cp ./dist/index.html ./dist/404.html && echo "pro.abckey.com" > ./dist/CNAME
      - name: deploy to target directory
        uses: crazy-max/ghaction-github-pages@v1
        with:
          target_branch: gh-pages
          build_dir: dist
          repo: abclib/pro.abckey.com
        env:
          GITHUB_TOKEN: ${{ secrets.MY_DEPLOY_KEY }}
          GITHUB_PAT: ${{secrets.MY_DEPLOY_KEY}}

push 代码后，编译过程如下

这样，整个自动打包上传的过程就结束了。

0202 年了，利用好工具真的可以提高工作效率噢，让我们一起向那个刀耕火种的手动时代说再见吧。