一、CI持续集成简介
1、CI持续集成简介
CI（Continuous Integration），即持续集成，是一种可以增加项目可见性、降低项目失败风险的开发实践，其目的在于让产品快速迭代的同时，尽可能保持高质量。每次集成都通过自动化的构建（包括编译、发布、自动化测试)来验证，从而尽快地发现集成错误，只有通过自动测试的代码才能进行后续的交付和部署。
CI是团队成员间（产研测）更好地协调工作，更好的适应敏捷迭代开发，自动完成减少人工干预，保证每个时间点上团队成员提交的代码都能成功集成的，可以很好的用于对Android/iOS项目的打包。
2、持续集成的优点
A、快速发现错误
每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
B、防止分支大幅偏离主干
如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
3、持续集成的原则
持续集成的原则包括：
A、需要版本控制软件保障团队成员提交的代码不会导致集成失败。
B、开发人员必须及时向版本控制库中提交代码，必须经常性地从版本控制库中更新代码到本地。
C、需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次。
D、必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。
4、持续集成系统的组成
一个完整的构建系统必须包括：
A、一个自动构建过程，包括自动编译、分发、部署和测试等。
B、一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。
C、一个持续集成服务器。
二、CD持续交付、持续部署
持续交付（Continuous delivery）是频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
持续部署（continuous deployment）是持续交付的下一步，是代码通过评审后，自动部署到生产环境。
三、GitLab-CI持续集成
1、GitLab-CI简介
GitLab-CI（GitLab Continuous Integration）是一套配合GitLab使用的持续集成系统（其它的持续集成系统同样可以配合GitLab使用，比如Jenkins），GitLab8.0以后的版本默认集成GitLab-CI并且启用。
GitLab CI是GitLab提供的持续集成服务，只要在仓库根目录创建一个.gitlab-ci.yml 文件， 并为工程指派一个Runner，当有合并请求或者 push的时候就会触发那么每一次合并请求（MR）或者push都会触发CI pipeline。
Pipelines是定义于.gitlab-ci.yml中的不同阶段的不同任务。
.gitlab-ci.yml文件定义GitLab runner要做哪些操作。 默认有3个[stages(阶段)]: build、test、deploy。
当build完成后(返回非零值)，会看到push的 commit或者合并请求前面出现一个绿色的对号。 方便开发者检查出来合并请求是否会导致build失败， 免去检查代码。
GitLab CI服务跑build测试， 开发者会很快得到反馈，知道自己提交的代码是否有BUG。
A、在仓库根目录创建一个名为.gitlab-ci.yml的文件
B、为工程配置一个Runner
每次push代码到Git仓库， Runner就会自动开始pipeline。
GitLab CI负责.gitlab-ci.yml脚本的解析，根据.gitlab-ci.yml脚本的规则，分配到各个Runner来运行相应的脚本script。
2、Runner脚本文件
.gitlab-ci.yml脚本文件必须用空格来缩进，不能用tab来缩进。
.gitlab-ci.yml脚本基本示例如下：
# 定义 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"stages关键字用于定义Pipeline中的各个构建阶段，然后用一些非关键字来定义jobs。每个job中可以可以再用stage关键字来指定该 job 对应哪个 stage。job 里面的 script 关键字是最关键的地方了，也是每个 job 中必须要包含的，它表示每个 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
要求 GitLab Runner 0.5.0+，定义环境变量。
如果定义了 Job 级别的环境变量的话，该 Job 会优先使用 Job 级别的环境变量。
cache && Job.cache
要求 GitLab Runner 0.7.0+
定义需要缓存的文件。
每个 Job 开始的时候，Runner 都会删掉 .gitignore 里面的文件。
如果有些文件 (如 node_modules/) 需要多个 Jobs 共用的话，我们只能让每个 Job 都先执行一遍 npm install。
这样很不方便，因此我们需要对这些文件进行缓存。缓存了的文件除了可以跨 Jobs 使用外，还可以跨 Pipeline 使用。
Job.script
定义Job要运行的命令，必填项。
Job.stage
定义Job的stage，默认为test。
Job.artifacts
定义Job中生成的附件。
当该 Job 运行成功后，生成的文件可以作为附件 (如生成的二进制文件) 保留下来，打包发送到 GitLab，之后我们可以在 GitLab 的项目页面下下载该附件。
.gitlab-ci.yml脚本工程实例：
stages:
- install_deps
- test
- build
- deploy_test
- deploy_production
cache:
key: ${CI_BUILD_REF_NAME}
paths:
- node_modules/
- dist/
# 安装依赖
install_deps:
stage: install_deps
only:
- develop
- master
script:
- npm install
# 运行测试用例
test:
stage: test
only:
- develop
- master
script:
- npm run test
# 编译
build:
stage: build
only:
- develop
- master
script:
- npm run clean
- npm run build:client
- npm run build:server
# 部署测试服务器
deploy_test:
stage: deploy_test
only:
- develop
script:
- pm2 delete app || true
- pm2 start app.js --name app
# 部署生产服务器
deploy_production:
stage: deploy_production
only:
- master
script:
- bash scripts/deploy/deploy.sh.gitlab-ci.yml脚本将Pipeline 分成五个阶段：
A、安装依赖(install_deps)
B、运行测试(test)
C、编译(build)
D、部署测试服务器(deploy_test)
E、部署生产服务器(deploy_production)
设置 Job.only 后，只有当develop分支和master分支有提交的时候才会触发相关的Jobs。
四、GitLab-Runner
1、GitLab-Runner简介
GitLab-Runner是配合GitLab-CI进行使用的。一般地，GitLab里面的每一个工程都会定义一个属于自己的软件集成脚本，用来自动化地完成一些软件集成工作。当工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将变动通知GitLab-CI。GitLab-CI会找出与工程相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。
Gitlab-runner
是.gitlab-ci.yml脚本的运行器，Gitlab-runner是基于Gitlab-CI的API进行构建的相互隔离的机器（虚拟机），GitLab Runner不需要和Gitlab安装在同一台机器上。构建任务会占用很多的系统资源 (譬如编译代码)，而GitLab CI是GitLab的一部分，如果由GitLab CI来运行构建任务的话，在执行构建任务的时候，GitLab的性能会大幅下降，因此，不建议Gitlab和GitLab Runner安装在同一台机器上。
Runner可以分布在不同的主机上，同一个主机上也可以有多个Runner。
GitLab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。
Shared Runner：所有开启Allow shared runners选项的工程都能够用，只有系统管理员能够创建Shared Runner。
Specific Runner：只能为指定的工程服务，拥有工程访问权限的人都能够为工程创建Specific Runner。
GitLab上所有的工程都有可能需要在公司的服务器上进行编译、测试、部署等工作，可以注册一个Shared Runner供所有工程使用。
如果在工作机或者服务器上自动构建开发者参与的某个工程，可以注册一个Specific Runner。
对于GitLab的普通用户，没有管理员权限，如果同时参与多个项目，就需要为所有项目都各注册一个Specific Runner，就需要在同一台机器上注册多个Runner。
gitlab-runner是gitlab-ci-multi-runner的符号链接。
2、添加gitlab-runner仓库
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash添加gitlab-ci-multi-runner仓库国内镜像：
[gitlab-ci-multi-runner]
name=gitlab-ci-multi-runner
baseurl=http://mirrors.tuna.tsinghua.edu.cn/gitlab-ci-multi-runner/yum/el7
repo_gpgcheck=0
gpgcheck=0
enabled=1
gpgkey=https://packages.gitlab.com/gpg.key3、安装gitlab-runner
sudo yum install gitlab-runner4、启动gitlab-runner
sudo gitlab-ci-multi-runner start设置开机启动：
echo "sudo gitlab-ci-multi-runner start" >> /etc/rc.local5、注册 Runner
Runner需要注册到Gitlab才可以被工程所使用，一个gitlab-ci-multi-runner服务可以注册多个Runner。
sudo gitlab-ci-multi-runner register交互界面如下：
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci):
http://192.168.1.2/ci //输入gitlab安装的服务器ip/ci，CI URL
Please enter the gitlab-ci token for this runner:
eaYyokc57xxZbzAsoshT // 指定Gitlab上工程的Runners选项的注册token
Please enter the gitlab-ci description for this runner:
[E5]: spring-demo // 填写runner描述信息
Please enter the gitlab-ci tags for this runner (comma separated):
demo // 填写tag信息，多个tag可通过逗号,分割。
Registering runner... succeeded runner=eaYyokc5
Please enter the executor: docker, docker-ssh, parallels, shell, ssh, virtualbox, docker+machine, docker-ssh+machine:
shell //输入runner执行方式，Gitlab和runner安装在同一台服务器上，输入shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!向GitLab-CI注册一个Runner必须有：GitLab-CI的url和注册token。
token用于确定Runner是所有工程都能够使用的Shared Runner还是具体某一个工程才能使用的Specific Runner。
如果要注册Shared Runner，需要到管理界面的Runners页面里面查找注册token。使用管理员登录，点击Admin Area菜单，右侧导航栏Runners，Shared Runner信息如下：
对于工程的Specific Runner信息可以通过查看GitLab中工程管理的Projects下拉菜单选择Your Project->Settings->CI/CD->Runners settings。
在Runners settings中可以查看工程相关的Specific Runner信息。
注册Runner完成后，可以用sudo gitlab-ci-multi-runner list 命令来查看各个Runner的状态。
通过gitlab-ci-multi-runner register注册的Runner配置会存储在/etc/gitlab-runner/config.toml中，如果需要修改可直接编辑该文件。
GitLab-CI会为每个Runner生成一个唯一的token，以后Runner就通过token与GitLab-CI进行通信。
在类Unix操作系统下：
如果以root用户身份运行gitlab-ci-multi-runner register，配置文件默认是/etc/gitlab-runner/config.toml
如果以非root用户身份运行gitlab-ci-multi-runner register，配置文件默认是~/.gitlab-runner/config.toml
在其他操作系统下：
配置文件默认在当前工作目录下./config.toml
6、运行Runner
Runner注册完成后必须运行起来，否则无法接收到GitLab-CI的通知并且执行软件集成脚本。
运行单个Runner命令：
gitlab-ci-multi-runner run-single要让一个Runner运行起来，--url、--token和--executor选项是必要的。其他选项可根据具体情况和需求进行设置。
gitlab-ci-multi-runner run-single --url url --token token --shell批量地运行Runner命令：
gitlab-ci-multi-runner run-c, --config选项
用来指定配置文件路径。如果想同时运行多个Runner，必须知道要运行哪些Runner以及这些Runner运行时所需要的信息。配置文件里面就存放着Runner运行时所需要的信息，一个配置文件是可以存放多个Runner的信息。如果不指定本选项，就会使用默认的配置文件。
-n, --service选项
本选项用来指定服务的别名。一次只能运行一批Runner，因为一次只能指定一个配置文件。如果有多个配置文件，要运行多批Runner，给每一次批量运行服务取不同的别名。
-d, --working-directory选项
本选项用来指定此次批量运行服务的工作目录。如果自己没有指定builds_dir，此次运行起来的Runner会把builds_dir放到目录里面。
-u, --user选项
本选项指定以什么用户权限来运行Runner。为了安全，不应该给运行Runner的用户过高的权限，更不应该以root用户来运行Runner。
--syslog选项
本选项指定把日志记录到系统日志。
启动服务后，运行命令ps -aux | grep gitlab-runner查看后台程序，发现启动服务其实就是在后台执行了一个批量运行Runner的任务
