Git 工作流

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

分支的定义及作用

以下是我目前所在的团队定制的分支管理流程

一套适用于自己团队的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的定义文件以上仅做了简单的示例，自动化部署则需要我们去定义不同的任务各司其职，具体的配置详情请关注

• 深入浅出，前端团队的自动化部署指南 - 配置篇 (未发布)
• 深入浅出，前端团队的自动化部署指南 - 高级篇 (未发布)