介绍下我们现在的前端部署方式，主要有以下功能要在CI实现

1. 安装依赖
2. 编译代码
3. 上传资源文件到云存储
4. 部署服务器代码

.gitlab-ci.yml文件

image: node:8.9.3
stages:
  - build
  - test
  - deploy

masterbuild:
  stage: build
  script:
    - npm install --no-optional
    - npm run prod
    - node ./tools/generate.config.js
    - qshell='./tools/qshell-linux-x64'
    - chmod a+x "${qshell}"
    - ${qshell} account "${QINIU_AK}" "${QINIU_SK}"
    - ${qshell} qupload 8 ./qiniuconfig
  only:
    - master
  artifacts:
    expire_in: 1 week
    paths:
      - dist

deploy_master:
  image: sebble/deploy
  stage: deploy
  script:
    - mkdir -p ~/.ssh
    - echo "$PROD_DEPLOY_SSH" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - rsync -rav  dist/ "$PROD_DEPLOY_USER"@"$PROD_DEPLOY_HOST":/deploy_path
  only:
    - master

---

解释下部署代码，先看下build阶段的

    - npm install --no-optional
    - npm run prod

这个是安装依赖和编译的

    - node ./tools/generate.config.js

这个是生成七牛配置信息的，可根据实际情况修改，七牛qshell文档

{
    "src_dir": "",
    "bucket": "",
    "key_prefix": "",
    "up_host": "http://up-z2.qiniup.com",
    "overwrite": true,
    "skip_fixed_strings": ".svn,.git",
    "skip_suffixes": ".DS_Store,.exe",
    "log_stdout": true
}

我这生成的配置是这样，配置下要上传的目录和bucket，指定下前缀等

    - qshell='./tools/qshell-linux-x64'
    - chmod a+x "${qshell}"
    - ${qshell} account "${QINIU_AK}" "${QINIU_SK}"
    - ${qshell} qupload 8 ./qiniuconfig

用七牛的工具把资源文件（css,js,图片,音频）上传到七牛，一些变量信息，为了共用，写到项目组的CI / CD的Variables里面了

only:
    - master

这个是指定只有master分支可以触发这个job

  artifacts:
    expire_in: 1 week
    paths:
      - dist

artifacts主要是把编译结果保存起来，供下一阶段使用，还有就是有的时候要下载下来看下代码有问题，expire_in指定缓存文件过期时间，paths指定要缓存的目录和文件

build阶段主要做这些事情

---

再来看下deploy阶段

    - mkdir -p ~/.ssh
    - echo "$PROD_DEPLOY_SSH" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - rsync -rav  dist/ "$PROD_DEPLOY_USER"@"$PROD_DEPLOY_HOST":/deploy_path

首先创建一个.ssh目录，把服务器的私钥写到id_dsa，然后用rsync把编译结果上传到我们的服务器，变量也是写到Variables里面了

这样我们就完成了一个前端项目的自动部署的配置，这样就完了？

你刚才上传那么资源到七牛有什么意义呢？如果你问这个问题，说明你跟着思路认真看下来了，没错，还没完，我们还要把我们生成的html文件的资源链接改成七牛的地址

找到webpack配置文件的output配置项

output: {
        publicPath: webebagconfig.getOutPutPath()
    }

我们生产环境和测试的是分开的，我这一步是在npm run prod做的，根据命令getOutPutPath()函数返回不同的域名

---

现在我们就完成一个前端项目的自动部署，上传资源到七牛（CDN）了，说到CDN，大家配置文件输出的时候，文件名一定要加上hash，保证每次部署的时候，都能生效，如果可以的话，最好前缀也加上，我这是用日期，部署完成后，我看前端加载资源的前缀就知道有没有部署成功，是不是用的缓存，webapck的输出的filename我是这样配置的assets/js/[name].[chunkhash:8].bundle.js

---

为什么要用两个阶段，一个不行吗？

为什么有build和deploy阶段，一个build就行了啊，一开始我也是只有一个build，后面因为遇到一件事，才把这个过程分成两个阶段来的，有一次部署的时候，新部署的程序有点问题，想回滚到上一个版本，然后npm抽风了，下载依赖非常慢，等了5分钟才部署好，分成两个阶段的话，如果artifacts还没有过期，就可以跳过build直接执行deploy，直接部署文件就行了，不需要再下载依赖和编译了，非常快

---

用CI部署的时候，如果中间某个步骤因为网络问题，中断了，可以在CI/CD -> Pipelines下面，点Run Pipeline，在Create for选你要触发的分支，点Create Pipeline触发一下就会自动执行相应的CI，发版本的时候，最好每个版本都打上tag，这样回滚版本非常方便，方法同上。

用CI还有个好处，我指服务端开发，前端可以参考，因为也出现过类似问题，有些新同事开发的时候，代码测试不严禁，上次调试代码加了个打印进去，加了个log包，把bug修改好了，把打印去掉，直接就推代码了，按以前那种方式，服务器拉下来编译肯定不通过，因为引用了log包但没有用到，用CI的话，如果编译不通过，后面就不会执行了，也就不会把有问题的程序部署到服务器，CI可以保证部署到服务器的是正常的程序。

---

最后打个广告

招前端、服务端开发，简历投递：liubin#readboy.com，#替换成@，简历标注：简书