背景:

所在的项目组中由于项目多是基于各种热点活动、工具和一些流量为主的h5页面，所以每个月基本都有4个左右的h5项目，项目多有拉流、工具效能类的页面，虽然不复杂，但是来来回回有很多的项目目录，所以项目管理和部署的时候就很是麻烦。
​

之前的过程：

​

由于通常项目都是相对较轻量，所以都是每人负责独立的项目，只有极个别大的项目会一起开发，所以我们都是采取通过SFTP协议，在本地build好dist文件然后直接拖到两台服务器中。
​

痛点：
​

由于之前一直没有集成自动化部署，所以每次上线都需要前端去连接两台服务器（负载均衡）分别去拉新代码和部署到线上，加上要去连接集团内网环境，所以每次部署都很繁琐。
​

期望的过程：

通过集成gitlab的gitlab-runner服务来实现自动化部署，项目merge到线上master分支上自动将代码push到两台服务器上并完成部署；也可以通过push不同的分支实现测试服和正式服的互不干扰上线，测试和线上代码不会相互污染。中间省略了通过VPN登录集团服务器然后手动部署代码的过程，我们也只需要关注代码本身。

gitlab-runner的实现

1. 添加GitLab Runner yum源

   curl -L <https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh> | sudo bash
   
   

2. 安装gitlab-runner

   yum install gitlab-ci-multi-runner
   
   

3. 向GitLab-CI注册Runner

提示：即让Runner与GitLab-CI建立联系，告诉GitLab-CI你有啥需要部署到我所在服务器的就告诉我一声我来给你在这台服务器上执行。
​

[root@localhost ~]# gitlab-ci-multi-runner register

1.Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://192.168.1.60:8090/ （说明：url参考下方图片）
                                            
2.Please enter the gitlab-ci token for this runner:
yLxk5Eaj1jYXnAJS5*** （说明：token参考下方图片）

3.Please enter the gitlab-ci description for this runner:
[localhost.localdomain]: focus-runner-des （runner的描述名称，随便DIY能有效区分就行）

4.Please enter the gitlab-ci tags for this runner (comma separated):
focus-runner-tags （runner的tags名称，随便DIY能有效区分就行）

5.Whether to run untagged builds [true/false]:
[false]: true
（说明：将来runner被执行时，如果构建文件没有tags标记是否允许执行这个runner，一般选false，可根据需要选择）

6.Whether to lock Runner to current project [true/false]:
[false]: true （说明：是否锁定这个runner为这个项目所用） 

7.Please enter the executor: docker-ssh, parallels, ssh, virtualbox, kubernetes, docker, shell, docker+machine, docker-ssh+machine:
shell （没有使用docker部署，这里选择shell，通过shell脚步来实现自动化部署）

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

当出现有：

绿色状态的runner服务时，表示gitlab-runner服务注册成功。
​

查看runner所在主机上有哪些runner是活着的：
gitlab-runner verify

如果发现runner不是活着的可以启动runner服务
sudo gitlab-runner run
（说明：runner注册之后默认是自动启动的，但如果这个runner没有启动则你的pipeline在后续执行runner时将一直处于pending状态。）

注意：如果是非root用户，注意赋予相对应的权限，不然在执行cp、move等命令行的时候可能会出错。
​

服务配置好了然后就是编写脚本，告诉服务如何自动化执行脚本。
在项目根目录下创建**.gitlab-ci.yml**文件，具体配置选项可以参考文档，我的项目暂且如下，还在优化中：

stages: # 分段
  - service_1
  - service_2

cache: # 缓存
  paths:
    - node_modules
service_1:
  stage: service_1
  only:
    - master
  script:
    - cd /home/project/hands_on_skill
    - git pull origin master
    - yarn build
  tags:
    - hands_on_skill_1

service_2:
  stage: service_2
  only:
    - master
  script:
    - cd /home/project/hands_on_skill
    - git pull origin master
    - yarn build
  tags:
    - hands_on_skill_2

通过两个stages、tags区分了两台服务器上对应项目的gitlab-runner服务，当然也可以在细分，整个流程可视化就更容易观察，捕获到哪里失败。
​

将**.gitlab-ci.yml**文件推送到gitlab仓库中，在gitlab项目页面中打开CI/CD-Pipelines，即可看到效果，如下图



看到这种情况即表示gitlab-runner运行成功。
​

​

遇到的问题：由于gitlab-runner会在服务器上创建一个项目文件夹，开始想着是在这个里边build成功后然后通过cp命令或者move命令直接移动到对应的线上访问的目录中，但是发现两台服务器在gitlab-runner文件夹下build生成的文件hash值不同，导致线上访问会出现问题，所以暂时先这样处理，后续在研究研究。目前这种方案可以实现自动化build但是，在build的时候，线上可能会出现短暂的白屏。