前端持续集成

一、定义

持续集成（continuous integration）是一种软件开发实践，即团队开发成员经常集成它们的工作（即将代码合并到公共分支上），通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

二、好处

1、减少风险，每天都进行集成并且每次集成都经过了相应的测试，可以较为快速的定位错误
2、防止分支大幅度偏离主分支，后期难以集成
3、减少手动发代码的重复工作量
4、增强项目的可见性，项目成员均可了解项目情况，有利于团队协作

三、集成工具

集成工具有比较多，本文介绍的是GitLab CI

GitLab CI是GitLab内置的进行持续集成的工具，只需要在仓库根目录下创建.gitlab-ci.yml 文件，并配置GitLab Runner，每次提交的时候Gitlab将自动识别到.gitlab-ci.yml文件，并且使用Gitlab Runner执行该脚本。

GitLab CI由以下两个模块组成:
gitlab-ci server:负责调度、触发Runner,以及获取返回结果.
gitlab-ci-runner:则是主要负责来跑自动化CI（测试，编译，打包等）。

Gitlab Runner就是一个用来执行.gitlab-ci.yml脚本的工具，可以理解成GitLab-CI就像是管理中心，runner入职成为管理员，首先要办理入职手续（即注册），并说明自己负责哪个项目，后续当相应的项目发生变化时，GitLab-CI就会通知相应的runner响应变化（即执行对应的脚本）。

GitLab-Runner可以分成两种类型：
Shared Runner（共享型）：所有工程都能够用的，且只有系统管理员能够创建。
Specific Runner（指定型）：只有特定的项目可以使用。

四、GitLab CI实践

1、安装Runner

Runner安装步骤(linux为例)：

// 下载
curl -LJO https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_<arch>.rpm
// 安装
rpm -i gitlab-runner_<arch>.rpm

其余系统安装可参考官网文档

2、注册Runner

gitlab-runner register

之后会要求输入gitlab的url和token，进入gitlab仓库，点击左侧菜单栏的Settings -> CI/CD,展开Runners的设置项即可查找到相应的url和token。再根据提示输入Runner的描述、tag以及运行平台（本文选择shell）。注册完成后可以在刚刚查找gitlab的url和token的地址看到新建立的tag。

3、.gitlab-ci.yml

服务器上完成了gitlab-runner的安装和注册后，我们就需要在项目的根目录下建立一个.gitlab-ci.yml文件，.gitlab-ci.yml 文件定义GitLab runner要做哪些操作。基本示例如下：

# 定义 stages
stages:
    - dev
    - sit

# 定义变量
variables:
    project: projectName

# 定义 job
dev-job1:
    stage: dev
    only:
        refs:
            - /^dev$/
        variables:
            - $CI_COMMIT_MESSAGE =~ /\-\-build/
    script:
        - echo "I am the dev job "
        - sh xxx.sh
    tags:
        - dev

# 定义 job
sit-job1:
    stage: sit
    only:
        refs:
            - /^sit$/
        variables:
            - $CI_COMMIT_MESSAGE =~ /\-\-build/
    script:
        - echo "I am the sit job"
        - sh xxx.sh
    tags:
        - sit

stages

每个推送到Gitlab的提交都会产生一个与该提交关联的管道(pipeline)，若一次推送包含了多个提交，则管道与最后那个提交相关联，管道(pipeline)就是一个分成不同阶段(stage)的任务(job)的集合。可以理解成pipeline就像是一条流水线，每条流水线上会有很多的阶段，每个阶段上会有相应的任务。

所有Stages会按照顺序运行，同一state中的job会并行执行，都执行成功了，该stage才会成功。当一个Stage完成后，下一个Stage才会开始，只有当所有 Stages完成后，该构建任务 (Pipeline) 才会成功。如果同一state中的任何一个job执行失败，则该state执行失败，如果任何一个Stage失败，那么后面的 Stages不会执行，该构建任务 (Pipeline) 失败。

variables

除了Runner自定义的变量之外，也可以根据自己的需求自定义构建变量。

jobs

每个job都必须有一个唯一的名字。它由一系列参数来定义job的行为。
stage：标明该job属于哪一个stage;
only：定义该job执行条件，示例中dev-job1执行的条件就是必须是dev分支，并且提交信息中要添加构建命令--build;
script：runner执行的命令或脚本，这里需要执行一个shell脚本，将项目构建打包，并将打包后的文件放到相应的域名文件夹下完成发布。

job的完整关键字可见参考官网

tags

可以从允许运行此项目的所有Runners中选择特定的Runners来执行该job。(第二步中注册runner的时候设置的tag)

4、构建发布

相应分支的代码提交时，在提交信息中增加--build指令，即可完成自动测试构建发布。