Gitlab CI / CD 持续集成
持续集成
概念
简单说就是指,频繁的(一天多次的)的将代码集成到主干。
与持续集成相关的两个概念:
持续交付
指的是,可频繁地将软件的新版本交付给质量团队,以供评审。评审通过,即可部署到生产环境。
持续交付强调的是,不管怎么更新,软件都可以随时交付。
持续部署
持续交付的下一步,代码经过评审通过后,自动部署到生产环境。
持续部署的目标是,代码在任何时候都可以部署到生产环境。
目的
持续集成流程
如图
代码提交 -> 测试(单元测试、集成测试、端到端测试) -> 构建 -> 部署
常用的持续集成平台
Gitlab CI / CD
简介
Gitlab
自带的一套持续集成系统,通过根目录下的 .gitlab-ci.yml
文件配置的规则,调用对应的 Gitlab Runner 来执行相应的构建任务。
.gitlab-ci.yml
使用 YAML
语言,YAML 是一个可读性高,以数据做为中心,用来表达数据序列的格式。 -- YAML wikipedia
.gitlab-ci.yml
位于项目根目录,用来配置(记录) Gitlab CI/CD
持续集成的一系列阶段,每个阶段执行不同的任务。
Gitlab Runner
任务(脚本)执行的承载者,.gitlab-ci.yml
的 script 部分就是由 Gitlab Runner
来负责执行的。
Gitlab CI 根据项目里根目录的 .gitlab-ci.yml 文件的规则,将每个阶段的每个任务中的 script 脚分配给对应的 Gitlab Runner 来执行,这些脚本包括安装依赖的,测试的,部署的等。
Gitlab CI/CD 持续集成过程
Commit 或 Pull Request -> Gitlab -> Gitlab CI/CD -> Gitlab Runner 1/2/3/...
安装 Gitlab Runner
本机安装
macOS / linux / windows 官网下载安装包安装即可
Gitlab Runner Docker Image 本地安装(MacOS)
1. 安装 Docker
docker官网下载安装包安装即可。
2. 拉取 Gitlab Runner Docker Image
$ docker pull gitlab/gitlab-runner:latest
3. 运行 Gitlab Runner Container
$ docker run -d --name gitlab-runner --restart always \
-v /Users/Shared/gitlab-runner/config:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest
4. 注册 Runner
进入 gitlab-runner 容器内部
- 查看容器id
- 进入容器内部
$ docker exec -it containerID /bin/bash
注册 Runner
- 注册
$ gitlab-runner register
# Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
# https://gitlab.com/
- 输入 token
可在Gitlab UI项目中的设置 -> CI/CD选项中查看
# Please enter the gitlab-ci token for this runner:
#
- 输入 Runner 描述
#Please enter the gitlab-ci description for this runner:
# [4c554f0df65c]: locally gitlab-ci runner
- 给Runner指派tags
- 相当于Runner的唯一id
- 可指派多个,表示此 Runner 仅执行 tags 内的任务。在 .gitlab-ci.yml 的每个任务中设置 tags 选项来指派对应 Runner 来执行任务
- 也可为空,表示此 Runner 可执行任何任务
# Please enter the gitlab-ci tags for this runner (comma separated):
# test,develop,feature
- 选择 Runner 的执行载体
# Please enter the executor: docker+machine, docker-ssh+machine, docker, ssh, virtualbox, kubernetes, docker-ssh, parallels, shell:
# docker
在此选择docker,下一步设置默认镜像,用于 .gitlab-ci.yml 中未指定镜像的任务
# Please enter the default Docker image (e.g. ruby:2.1):
# node:alpine
# Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
- 查看 Runner 是否启动并注册成功
可在 Gitlab UI 中查看
或
$ gitlab-runner verify
# Verifying runner... is alive
编辑 .gitlab-ci.yml 配置文件
CI/CD 关键词
Pipeline
即流水线,一次 pipeline 相当于一次构建任务。包含多个阶段和任务,如安装依赖、测试、部署等。
Stages
一次构建任务中的构建阶段。
一次 Pipeline 中可定义多个 Stages,每个 Stage 可以包含多个任务。
所有阶段会按定义顺序的执行,即当一个阶段的任务全部成功执行完毕后,下一个阶段才开始.
Jobs
构建任务,某个 Stage 里需要执行的任务,可以在 Stage 中定义多个 Jobs。
Jobs 特点:
- 相同 Stage 中的 Jobs 并行执行
- 相同 Stage 中的所有 Jobs 都执行成功时,该 Stage 才会标记成功
- 任何一个 Job 执行失败,那么该 Stage 失败,该构建任务 Pipeline 失败
Pipeline、Stages、Jobs 关系
![pipeline-stages-jobs](https://user-images.githubusercontent.com/20431351/56122038-139f6800-5fa4-11e9-9fcf-7ea94003e356.png)
任何 commit 或 pull request 都会触发 pipeline
.gitlab-ci.yml 示例
一个vue cli 3默认生成的项目的部署脚本
# 指定 CI 默认使用的 docker 镜像
image: node:alpine
# 构建阶段
stages:
- init
- test
- build
- deploy
# init 阶段任务
initJob:
stage: init
# 缓存 node_modules 目录
cache:
# Gitlab CI 预定义变量
key: ${CI_BUILD_REF_NAME}
paths:
- node_modules
# 指定 Runner Tags
tags:
- test
script:
# 设置淘宝镜像地址
- npm set registry https://registry.npm.taobao.org
- npm install --progress=false
# test 阶段任务
testJob:
stage: test
# 使用缓存
cache:
key: ${CI_BUILD_REF_NAME}
paths:
- node_modules
# 跳过上传cache
policy: pull
tags:
- test
script:
# 由于 cache 并不保证每次都命中(即拿到的cache可能为空),如果为空,重新生成
- if [ ! -d "node_modules" ]; then
- npm install --progress=false
- fi
- npm run test
# build 阶段任务
buildJob:
stage: build
cache:
key: ${CI_BUILD_REF_NAME}
paths:
- node_modules
# 跳过上传cache
policy: pull
tags:
- test
script:
- if [ ! -d "node_modules" ]; then
- npm install --progress=false
- fi
- npm run build
# 缓存打包后的文件
artifacts:
expire_in: 1 week
paths:
- dist
# deploy 阶段任务(仅主干提交时执行此任务)
master_deploy:
stage: deploy
tags:
- test
# 部署脚本
script:
- bash delop.sh
# 设置依赖哪个任务传递来的 artifacts
dependencies:
- build
# 执行执行此任务的分支
only:
- master
# 执行方式
when: manual
Gitlab CI yaml官方配置文件翻译
配置自定义变量
可以在 Gitlab UI 中配置一些任务执行中需要用到的数据,比如 SSH 私钥,服务器地址、端口等敏感数据
![配置自定义变量](https://user-images.githubusercontent.com/20431351/56121755-6b899f00-5fa3-11e9-85b6-b289453db09b.jpg)
cache 与 artifacts
在GitLab-CI中, cache与artifacts比较容易混淆。
其中 cache 指的是缓存, 常用于依赖安装中, 如几个jobs都需要安装相同的依赖, 可以使用依赖,此时可以加快依赖的安装进度;
对于 artifacts 则是将某个工件上传到 GitLab 提供下载或后续操作使用。
由于每个 job 启动时,都会自动删除 .gitignore 中指定的文件, 因此对于依赖安装目录, 即可以使用cache, 也可以使用 artifacts。
两个主要有以下几个区别:
-
虽然定义了 cache, 但是如果 cache 和 .gitignore 中重复的这部分, 仍然需要重新安装
重新安装时因为使用的是缓存, 所以很有可能不是最新的。
-
特别是开发环境, 如果每次都希望使用最新的更新, 应当删除cache, 使用 artifacts, 这样可以保证确定的更新
-
artifacts 中定义的部分, 会自动生成, 并可以传到下面的 job 中解压使用, 避免了重复依赖安装等工作
-
如果使用 Docker 运行 Gitlab-Runner, cache 会生成一些临时容器, 不容易清理, artifacts 可以设置自动过期时间, 过期自动删除
-
artifacts 会先传到 GitLab 服务器, 然后需要时再重新下载, 所以这部分也可以在 GitLab 下载和浏览