简介
GitLab
是一套基于 Ruby 开发的开源 Git 项目管理应用, 其提供的功能和 Github 类似, 不同的是 GitLab 提供一个 GitLab CE 社区版本, 用户可以将其部署在自己的服务器上, 这样就可以用于团队内部的项目代码托管仓库.
GitLab CI
是 GitLab 提供的持续集成服务(从 8.0 版本之后, GitLab CI 已经集成在 GitLab 中了), 只要在你的仓库根目录下创建一个. gitlab-ci.yml 文件, 并为该项目指派一个 Runner, 当有合并请求或者 Push 操作时, 你写在. gitlab-ci.yml 中的构建脚本就会开始执行.
GitLab Runner
是配合 GitLab CI 进行构建任务的应用程序, GitLab CI 负责 yml 文件中各种阶段流程的执行, 而 GitLab Runner 就是具体的负责执行每个阶段的脚本执行, 一般来说 GitLab Runner 需要安装在单独的机器上通过其提供的注册操作跟 GitLab CI 进行绑定, 当然, 你也可以让其和 GitLab 安装在一起, 只是有的情况下, 你代码的构建过程对资源消耗十分严重的时候, 会拖累 GitLab 给其他用户提供政策的 Git 服务.
持续集成 / 部署环境
持续集成是程序开发人员在频繁的提交代码之后, 能有相应的环境能对其提交的代码自动执行构建 (Build), 测试(Test), 然后根据测试结果判断新提交的代码能否合并加入主分支当中, 而持续部署也就是在持续集成之后自动将代码部署(Deploy) 到生成环境上
开启 GitLab CI 功能
在 GitLab 8.0 版本之后, 你可以通过如下两部启用 GitLab CI 功能
新建一个. gitlab-ci.yml 文件在你项目的根目录
为你的项目配置一个 GitLab Runner
配置一个. gitlab-ci.yml 文件
.gitlab-ci.yml 文件是用来配置 GitLab CI 进行构建流程的配置文件, 其采用 YAML 语法, 所以你需要额外注意要用空格来代替缩进, 而不是 Tabs. 下面通过我自己项目中的. gitlab-ci.yml 文件来具体介绍其规则
- stages:
- - init
- - check
- - build
- - deploy
- cache:
- key: ${CI_BUILD_REF_NAME}
- paths:
- - node_modules/
- - dist/
- # 定义一个叫 init 的 Job 任务
- init:
- stage: init
- script:
- - cnpm install
- #master_check Job: 检查 master 分支上关键内容
- master_check:
- stage: check
- script:
- - echo "Start Check Eros Config ..."
- - bash check.sh release
- only:
- - master
- #dev_check Job: 检查 dev 分支上关键内容
- dev_check:
- stage: check
- script:
- - echo "Start Check Eros Config ..."
- - bash check.sh debug
- only:
- - dev
- js_build:
- stage: build
- script:
- - eros build
- master_deploy:
- stage: deploy
- script:
- - bash deploy.sh release
- only:
- - master
- dev_deploy:
- stage: deploy
- script:
- - bash deploy.sh debug
- only:
- - dev
在上面的例子中, 我们利用 stages 关键字来定义持续构建过程中的四个阶段 init,chec,build,deploy
关于 GitLab CI 中的 stages, 有如下几个特点:
所有 Stages 会按照顺序运行, 即当一个 Stage 完成后, 下一个 Stage 才会开始
只有当所有 Stages 完成后, 该构建任务 (Pipeline) 才会成功
如果任何一个 Stage 失败, 那么后面的 Stages 不会执行, 该构建任务 (Pipeline) 失败
然后我们利用 caches 字段来指定下面将要进行的 job 任务中需要共享的文件目录, 如果没有, 每个 Job 开始的时候, GitLab Runner 都会删掉. gitignore 里面的文件
紧接着, 我们定义了一个叫做 init 的 job, 其通过 stage 字段声明属于 init 阶段, 因此, 这个 job 会第一个执行, 我们在这个 job 当中, 执行一些环境的初始化工作.
接下来是 check 阶段, 用来检查代码的一些基础错误(代码规范之类不会被编译器发现的问题), 以及一些配置文件的检查, 我将其命名为 master_check 和 dev_check, 通过 only 字段来告诉 GitLab CI 只有当对应的分支有 push 操作的时候才会触发这个 job.
然后就是代码的 build 阶段, 由于此阶段不像上个极端, 没有需要区分不同分支的命令, 所以就只需要定义一个 job 就够了
最后的 deploy, 因为不同的分支需要发布到不同的环境, 所以依然通过 only 来区分两个 job.
关于 GitLab CI 中的 Jobs, 也有如下几个特点:
相同 Stage 中的 Jobs 会并行执行
相同 Stage 中的 Jobs 都执行成功时, 该 Stage 才会成功
如果任何一个 Job 失败, 那么该 Stage 失败, 即该构建任务 (Pipeline) 失败
在我的这个构建任务当中, 根据我的业务情况只用到了少许关键字, 还有更多的类似于 before_script,after_script 等关键字, 具体的可以参阅 GitLab 的官方文档 https://docs.gitlab.com/ce/ci/yaml/README.html
在我们完成. gitlab-ci.yml 的流程编写之后, 就可以将其放在项目的根目录下, 然后 push 到我们的 GitLab 上, 这时, 如果你打开项目首页的 Piplines 标签页, 会发现一个状态标识为 pending 的构建任务, 如下图所示:
这时由于这个构建任务还有找到可用的 GitLab Runner 来执行其构建脚本, 等我们接下来为我们的项目接入 GitLab Runner 之后, 这些任务的状态就会由 pendding 变成 running 了
安装 GitLab Runner
找一台适合安装 GitLab Runner 的机器, 无论是 Windows 或者 Mac 还是 Linux 都行, 最好是那种比较空闲的能 24 小时开启的机器, 我们在 GitLab Runner 的官网 https://docs.gitlab.com/runner/install/ 找到我们平台的安装文件, 以及对应的安装流程. 由于笔者我准备安装 GitLab Runner 是一台闲置的 iMac 电脑, 因此我就在演示 MacOS 下 GitLab Runner 的安装:
GitLab Runner 在 macOS 和 Linux/UNIX 下安装流程是一样的, 都是直接下载已编译好的二进制包
下载对应 GitLab 版本的 GitLab Runner
如果你的 GitLab 是 10.0 之后的版本, GitLab Runner 可执行文件改名为 gitlab-runner
- sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
- sudo chmod +x /usr/local/bin/gitlab-runner
9.0~10.0 之间的版本
- sudo curl --output /usr/local/bin/gitlab-ci-multi-runner https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-darwin-amd64
- sudo chmod +x /usr/local/bin/gitlab-ci-multi-runner
9.0 之前, 由于 9.0 之后启用全新的 API4 接口, 所以如果你的 GitLab 是 9.0 以前的版本, 需要下载下面的版本, 否则会导致你的 GitLab Runner 注册不上
- sudo curl --output /usr/local/bin/gitlab-ci-multi-runnerhttps://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/v1.11.1/binaries/gitlab-ci-multi-runner-darwin-amd64
- sudo chmod +x /usr/local/bin/gitlab-ci-multi-runner
不知道各位有没有注意到上面下载地址链接当中的 v1.11.1, 这个就是对应的 Gitlab Runner, 如果你的 GitLab 是 9.0 之前的版本, 使用 GitLab Runner v1.11.1 这个版本仍然注册不上, 可以尝试使用降几个版本的 GitLab Runner, 所有 GitLab Runner 发行的版本可以在 GitLab Runner Tags https://gitlab.com/gitlab-org/gitlab-runner/tags 找到
假如你遇到不能通过登录服务器来确定 GitLab 版本号时, 可以通过直接访问 gitlab 的首页, 后面加上 help, 如下图:
注册 GitLab Runner
执行下面命令,
sudo gitlab-ci-multi-runner register
如果你的终端提示找不到命令, 请通过
export PATH=/usr/local/bin:$PATH
将 / usr/local/bin 目录加入环境变量, 或者你遗漏了上面的 chmod 命令导致文件不可执行.
执行完上面的命令之后, 会让你输入下面的信息:
- Please enter the gitlab-ci coordinator URL:
- Please enter the gitlab-ci token for this runner:
- Please enter the gitlab-ci description for this runner
- Please enter the gitlab-ci tags for this runner (comma separated):
- Whether to run untagged builds [true/false]:
- Please enter the executor:
其中 coordinator URL 和 token 可以在你需要进行持续集成的项目的 Runner 标签页中找到
description 和 tags 可以自己定义, 是否 build 没有 tag 的提交这个也是根据你自己的需求来选择, 默认是 false,executer 选择 shell
填写完成之后如果提示
Registering runner... succeeded
表明这个 Runner 已经被注册成功了, 之后你在返回进入项目的 Runners 页面, 会发现下面多了一个处于 Active 状态的 Runner
紧接着最后一步, 启动我们刚注册的 Runner
sudo gitlab-ci-multi-runner start
现在, 我们切回项目的 Pipelines 当中, 肯定会发现之前处于 peding 状态的任务已经开始 running 了, 我们可以通过点击这个状态按钮来实时查看每个阶段的输出日志
开启构建状态的邮件提醒
如果你想收到关于每个构建任务的实时状态的邮件, 你可以在在项目中的 service 标签野种启用 Build Emails 这个服务.
结语
搭建一个快速方便的持续集成, 持续部署环境对于项目的开发来说是一个很重要的举措, 无论你是采用大名鼎鼎的 jenkins 还是本文介绍的 GitLab CI, 它不仅仅可以帮助我们节省大量的时间在调试发布部署当中, 也减少了我们因为人为因素导致的发布过程中出现的意外, 有效的较低了项目开发当中的风险.
来源: https://juejin.im/entry/5ad8627d6fb9a045d639b043