深入浅出，前端团队的自动化部署指南 - 环境篇

实践我用 21云盒子 来部署，一键自动部署全国CDN

Git 工作流
对于一个前端团队来说，Git的工作流是非常重要的，不仅有利于版本的管控和回滚，也在自动化部署方面可以做到细粒化的控制，在研究自动化部署之前，我想你应该先了解工作流并为你的团队定制一份合适的实现方案，目前流行的工作流是Git Flow，采用双主分支和其他辅助分支作为基本流程
分支的定义及作用
以下是我目前所在的团队定制的分支管理流程

分支
说明
是否受保护（不允许直接推送）

master
主分支，存储生产环境发布的所有代码，以Git tag作为版本管理
是

develop
开发分支，存储即将发布到生产环境的所有代码
否

feature/*
功能分支，以单个业务功能作为切分点
否

fix/*
功能修复分支，通常由develop切出并合并到develop
否

hotfix/*
热修复分支，通常由master切出并合并到master
否

beta/*
测试分支，结合多个业务功能发布到测试环境，beta下的子分支作为版本管理
是

release/*
灰测分支，结合多个业务功能发布到灰测环境，release下的子分支作为版本管理
是

一套适用于自己团队的Git工作流管理是非常重要的，所以自动化部署的前提是具备工作流方案
Gitlab
本文的自动化部署都是基于Gitlab的自动化CI/CD，所以你如果认同且需要这套方案，那么必要条件是Gitlab的私有化部署，市面上关于Gitlab安装的方案诸多，本文不再赘述
Gitlab Runner
Gitlab Runner 是 Gitlab 用来支持 CI/CD 方案的运行程序，我们的首要任务，是需要在一台服务器上成功搭建自己的Gitlab Runner，友情提示，Gitlab的安装尽量不要和Gitlab Runner程序在一台服务器上，另外Gitlab Runner程序比较占用系统CPU
安装
下载对应的 Gitlab Runner 版本
# Linux x86-64
wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Linux x86
wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386

# Linux arm
wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm
复制代码添加可执行权限
chmod +x /usr/local/bin/gitlab-runner
复制代码为Gitlab Runner注册一个用户
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
复制代码执行安装
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
复制代码为 Gitlab 添加 Runner 程序
在这一步，我们需要提前准备好几个必要的信息，打开内部部署的Gitlab网址，进入到管理中心界面，找到概览中的 Runner 菜单，你会看到如下的信息

你也可以为单个群组或者单个项目设置单独的Runner，打开的地址为群组下的设置、CI/CD中，我们更建议你为整个Gitlab搭建统一的Runner，然后可以在不需要的地方禁用掉该Runner
在这里我们可以拿到需要配置的URL和Token，接着需要执行
gitlab-runner register
复制代码然后有以下信息需要填写
Please enter the gitlab-ci coordinator URL # 刚刚拿到的`URL`路径
Please enter the gitlab-ci token for this runner # 刚刚拿到的`Token`令牌
Please enter the gitlab-ci description for this runner # 为你的程序制定一个简要的描述信息
Please enter the gitlab-ci tags for this runner (comma separated) # 输入多个tag，tag用于区分多个运行任务，使用,作为分隔符
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell
# 为你的Runner选择一个执行者，这里我们选择的是shell，也就是在当前环境执行，如果你选择docker或者kubernetes，你可能需要配置相应的运行环境
Please enter the Docker image (eg. ruby:2.1)
# 如果选择docker，那么需要指定一个docker运行的默认镜像，前端团队的话，运行的默认镜像应该是 node:latest
复制代码注册成功，则会看到如下提示
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
复制代码启动 Runner服务
gitlab-runner start
复制代码如果在项目的Runner管理界面看到如下提示，则说明Runner配置成功

启用 Gitlab CI
如上操作我们已经成功为项目配置了Runner程序，如何触发Runner程序完成我们的自动化部署，则需要用到Gitlab CI文件，Gitlab默认的文件名为.gitlab-ci.yml，首先应该在项目中创建一个这样的文件
stages:
  - test

cache:
  paths:
    - node_modules/

test:
  stage: test
  tags:
    - vue # tags 应该为你在某一个Runner指定的Tag，如果成功匹配到Runner，则会执行该任务
  script:
    - npm install --no-optional
    - npm run lint
复制代码测试 Runner
将添加了.gitlab-ci.yml文件的项目推送至服务器，如果文件配置正确，则会启动CI程序执行自动化检查，上面一个文件的配置是让Runner程序执行自动化代码检查，打开项目面板，找到CI/CD流水线，查看任务的执行状态

成功状态则说明当前分支的提交代码符合EsLint的预期规则，失败则说明代码检测失败，该分支则不能被合并到发布分支中，我们通常通过 test 任务来执行代码检查，以确保提交到线上的代码规范符合预期
各司其职
本文带来的是基于Gitlab Runner作为自动化部署的解决方案，Gitlab CI的定义文件以上仅做了简单的示例，自动化部署则需要我们去定义不同的任务各司其职，具体的配置详情请关注