概述
gitlab的持续集成功能很强大，在装好gitlab runner之后，项目根目录下上传一个.gitlab-ci.yml文件就可以启动持续集成/构建了。.gitlab-cli.yml的主要作用是配置构建的一系列任务。
有一些概念先要明白：
- pipeline/流水线： 一般是指一次构建过程，每次构建可能包含多个任务（编译、打包、测试、部署），就像工厂的流水线；
- job/任务：构建过程中的单个任务，如部署；
- environment/环境：单个任务的环境标签，如可给部署任务分为不同环境（生产、测试等）；
创建.gitlab-ci.yml文件
创建一个简单的配置文件，模拟一个构建过程，一般典型的构建过程有一些要求：
- 默认每次push代码都会触发自动构建，要求此类构建自动部署到测试服务器
- 可以手动部署到生产环境，测试环境
- 可以回滚
.gitlab-ci.yml
stages:
- build
- package
- deploy
build:
stage: build
tags:
- docbuild
script:
- echo "=============== 开始编译任务 ==============="
- echo "=============== 结束编译任务 ==============="
package:
stage: package
tags:
- docbuild
script:
- echo "=============== 开始打包任务 ==============="
- echo "=============== 结束打包任务 ==============="
deploy_test:
stage: deploy
tags:
- docbuild
script:
- echo "=============== 自动部署到测试服 ==============="
environment:
name: test
url: https://staging.example.com
deploy_test_manual:
stage: deploy
tags:
- docbuild
script:
- echo "=============== 手动部署到测试服 ==============="
environment:
name: test
url: https://staging.example.com
when: manual
deploy_production_manual:
stage: deploy
tags:
- docbuild
script:
- echo "=============== 手动部署到生产服 ==============="
environment:
name: production
url: https://staging.example.com
when: manual
运行
把.gitlab-cli.yml文件上传到项目的根目录下，如果已经配好了gitlab runner会立即触发自动构建。
可以在gitlab上查看流水线、任务以及环境，在环境中可以回滚到以前版本。
流水线界面列出执行过的构建，点击界面右侧红圈圈出的菜单，可以执行手动任务
任务界面
点击某个任务，进入任务详情页，可以看到任务执行时的输出
环境页面，列出了.gitlab-ci.yml配置的2个环境：test、production
点击进入某个环境的详情页，可以回滚到以前版本
