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

2,329 阅读5分钟

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 RunnerGitlab 用来支持 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

在这里我们可以拿到需要配置的URLToken,接着需要执行

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

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