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

本文主要是介绍深入浅出，前端团队的自动化部署指南 - 环境篇，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

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

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

这篇关于深入浅出，前端团队的自动化部署指南 - 环境篇的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！