简介
Continuous Integration(CI) 持续集成
Continuous Delivery(CD) 持续交付
Continuous Deployment(CD) 持续部署
持续集成的工作原理是将较小的代码块推送到 Git 仓库中托管的应用程序代码库中，并且每次推送时，都要运行一系列脚本来构建、
测试和验证代码更改，然后再将其合并到主分支中。持续交付和部署相当于更进一步的CI ，可以在每次推送到仓库默认分支的同时，将
应用程序部署到生产环境。
从Gitlab 8.0 开始，Gitlab CI 就已经集成在Gitlab 中 ，我们在项目中添加一个 .gitlab-ci.yml 文件，然后
添加一个 Runner ，即可进行持续集成。而且随着 Gitlab 的升级，Gitlab CI 也变的越来越强大。
一些概念
在简绍 Gitlab CI 之前，我们先了解一些持续集成相关的概念
Pipeline
一次 Pipeline 其实相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、
部署生成服务器等流程任何提交或者 Merge Request 的合并都可以触发 Pipeline ,如下图所示
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
Stages
Stage 表示构建阶段，说白了就是上面提到的流程。我们可以在一次 Pipeline 中定义多个 Stage ,这些 Stage 会有以下特点：
- 所有 Stages 会按照顺序允许，即当一个 Stage 完成后，下一个 Stage 才会开始
- 只有当所有 Stages 完成后，该构建任务 （Pipeline ）才会成功
- 如果任何一个 Stage 失败，那么后面的 Stage 不会执行，该构建任务（Pipeline）失败
因此 stages 与 pipeline 的关系就是
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
Job
Job 表示构建工作，表示某个 Stage 里执行的工作。我们可以在 stages 里定义多个 Jobs , 这些 Jobs 会有以下特点：
- 相同 Stage 中的 Jobs 会并行执行
- 相同 Stage 中的 Jobs 都执行成功， 该 Stage 才会成功
- 如果任何一个 Job 失败，那么该 Stage 失败，即构建任务(Pipeline)失败
所以，Jobs 与 Stage 的关系就是
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
Gitlab Runner
简介
理解了上面的概念后，有没有觉得少了些什么东西 ———由谁来执行这些构建任务？
答案就是 Gitlab Runner 了 ！
那么为什么不是Gitlab CI 来执行这些构建任务呢？
一般来说，构建任务都会占用很多系统资源，而 Gitlab CI 又是 Gitlab 的一部分，如果Gitlab 来执行构建任务的话，
在执行构建任务的时候，Gitlab 的性能会大幅下降。Gitlab CI 是管理各个构建项目的构建状态，因此，运行构建任务的
的事情交给 Gitlab Runner 。因为 Gitlab Runner 可以安装到不同的机器上 ， 所以在构建任务运行期间并不会影响到
Gitlab 的性能
安装
安装 Gitlab Runner 太简单了，按照官方文档来安装，下面是 Debian/Ubuntu/Centos 的安装方法，其他的需要参考官方文档
# For Debian/Ubuntu $ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash $ sudo apt-get install gitlab-ci-multi-runner # For CentOS $ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash $ sudo yum install gitlab-ci-multi-runner
注册 Runner
安装好 Gitlab Runner 之后，我们只要启动 Runner 然后和 CI 绑定就可以了
- 打开 Gitlab 中项目设置页面，在Runner 配置中查询 URL 与 Token
- 运行
sudo gitlab-ci-multi-runner register - 按照提示输入相关信息，最后输入 Runner 类型（简单测试使用 shell）
当注册好之后，可以用 sudo gitlab-ci-multi-runner list 命令查看Runner 的状态
.gitlab-ci.yml
简介
配置好 Runner 之后，我们要做的事情就是在项目中添加 .gitlab-ci.yml 文件。当我们添加了 .gitlab-ci.yml 文件后，每次提交代码
或者合并 MR 都会自动构建运行任务。
其实， .gitlab-ci.yml 就是定义 Pipeline 而已了
基本写法
# 定义 stages stages: - build - test # 定义 job job1: stage: test script: - echo "I am job1" - echo "I am in test stage" # 定义 job job2: stage: build script: - echo "I am job2" - echo "I am in build stage"
根据我们定的文件，build 阶段会在 test 阶段之前运行，所以 stage::build 的 job 会先运行，之后才会运行 stage:test 的 job
常用关键字
stages
定义stages ,默认有三个 stages ,分别是 build ,test ,deploy
types
stages 的别名
before_script
定义任何 Jobs 运行之前都会执行的命令
after_script
要求 Gitlab 8.7+ 和 Gitlab Runner 1.2+
定义任何 Jobs 运行完成后都会执行的命令
variables && Job.variables
定义环境变量，如果定义了 Job 级别的环境变量的话，会优先使用 Job 级别的环境变量
Runner 执行脚本部署
在Runner同台服务器上编写 lab.sh 脚本，脚本内部执行创建文件的操作。使用gitlab 来触发执行该脚本
# 定义 stages stages: - build - deploy # 定义 job deploy-pre: stage: build tags: - bzz script: - echo "I am job1" - echo "I am in test stage" # 定义 job deploy-post: stage: deploy tags: - bzz script: - bash /shell/lab.sh
执行过程第一次执行成功，但是并未创建文件。Runner 反馈无权限执行创建，也证明能够执行到脚本，修改Runner 的权限为 root 。执行成功，也成功创建文件
接下来执行部署项目
官方文档：https://docs.gitlab.com/ce/ci/yaml/README.html
使用参考: https://segmentfault.com/a/1190000006120164
Runner 安装: https://www.jianshu.com/p/fab407ddfed0
参考文章：https://www.cnblogs.com/cjsblog/p/12256843.html
Runner 执行shell 无权限：https://www.cnblogs.com/bafeiyu/p/12538861.html