前言

目前大多数的前端的上线流程依然是：开发人员本地开发完成后执行npm run build。随后将编译完成的目录copy之对应的线上服务器。最后提交本地代码至git。那么问题来了，当有多个开发人员对同一版本进行开发的时候，会不会出现前一秒我刚刚将我开发好的代码部署到测试环境，下一秒B同学又发了一次覆盖了我的呢？答案是肯定的。另外整个过程本地执行等待时间稍长或多或少会影响开发效率。那么怎样有效的规避这些问题，是我今天要分享给大家的。

准备工作

如文章标题，我们利用的是gitlab 提供的CI/CD 功能实现前端构建部署自动化，所以我们需要将代码用gitlab进行管理，我相信现在大多数公司应该都是用的它来管理的。其次我们需要准备一台机器（物理机、虚拟机都可以）来安装我们需要的环境。

开工

安装gitlab runner

gitlab官方有提供各个环境的安装文档

注册

1. 打开gitlab 进入某个项目，左侧菜单 => 设置 => CI/CD
2. 展开“RUNNDER",我们将会获得如下图所示的注册令牌
   
3. 终端执行

   $ gitlab-runner register
   

4. 输入第二步获取到的url
   
5. 输入注册令牌
   
6. 输入项目描述
   
7. 输入runner标签（我们用到的是docker）
   
8. 输入Runner的executor（继续输入docker）
   
9. 输入默认的docker镜像（根据自己的项目选择对应的docker镜像，也可以选择自己的本地docker镜像）
   
10. 如果你使用本地docker镜像的话，建议修改runner的配置文件:

     vi ~/.gitlab-runner/config.toml
     找到刚刚注册好的runner，在当前runner最后一行添加 pull_policy = "never"
     意为只拉取本地镜像
    

11. 执行

     $ gitlab-runner install
     启动runner服务：
     $ gitlab-runner start
    

至此，我们的runner服务就注册好了，接下来我们要将我们的项目做一点点修改

gitlab-ci.yml

GitLab CI使用YAML文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录，并且包含了你的项目如何被编译的描述语句。YAML文件使用一系列约束叙述定义了Job启动时所要做的事情。我们将下面的YAML文件放入你的项目根目录

image:nodetest

cache:
  key: 'node_modules'  
  paths:
    - node_modules/
    - package-lock.json


before_script:
  - git checkout "$CI_COMMIT_REF_NAME"
  - git reset --hard origin/"$CI_COMMIT_REF_NAME"
  - npm install 
  
stages:
  - build

build-project:
  stage: build
  cache:
    key: 'node_modules'
    policy: pull
    paths:
      - node_modules/
      - package-lock.json
      
  script:
  - npm run build

  tags:
    - docker
    
  only:
    refs:
    - /^master/
    - /^qa/
    - /^dev/
    variables:
    - $CI_COMMIT_MESSAGE =~ /^build/

上面的YAML文件大致意思为：一旦分支为master 、 qa 、 dev开头有提交信息为build开头的提交会触发build这个job
当然，这个YAML文件所触发的只是一个代码编译的事情，我们还需要将编译好的代码提取出来。大家需要根据自己的实际场景进行YAML文件的修改。

温馨提示与技巧

1. 如果你编译之后的文件需要放到另外一个仓库，请使用自己的docker镜像，该镜像里面可以添加ssh key，编译完成之后将其对应项目clone下来然后执行git的相关操作。
2. 使用自定义docker镜像，在docker中添加一个自己的npm插件，并在job中触发，比如编译部署完成之后给对应的开发人员发送邮件、企业微信群聊机器人通知等人性化操作
3. 如有不足之处还往指出
4. 外附一张我们的成品（现在我们的开发人员真的是爽歪歪）