Gitlab CI部署 & 业务中的应用

一、持续集成（Continuous Integration）

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

简单点说就是一键：合并代码---->安装依赖---->编译---->测试---->发布。

也可以简单点，不做服务端打包，只执行一键 测试---->发布。

二、GitLab-CI

GitLab-CI就是一套配合GitLab使用的持续集成系统（也有别的配合GitLab使用，比如Jenkins）。GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。

三、GitLab-Runner

GitLab-Runner是配合GitLab-CI进行使用的服务器脚本。
一般地，GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时，比如为某次commit打了tag，CI通知这些Runner把代码更新到本地并执行预定义好的执行脚本。

盗个图，简单明了。

Runner可以分布在不同的主机上，同一个主机上也可以有多个Runner。

Runner类型

Shared Runner：这种Runner（工人）是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
Specific Runner：这种Runner（工人）只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

四、GitLab-Runner的安装与使用

一、安装

下载

# Linux x86-64
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Linux x86
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386

# Linux arm
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm

添加权限

sudo chmod +x /usr/local/bin/gitlab-runner

运行(我们直接使用了root用户)

sudo gitlab-runner install --user=root --working-directory=/data1/cideploy/
sudo gitlab-runner start

二、注册。

执行，然后按照提示依次输入就完事了。 2~7 都是
```
sudo gitlab-runner register
```

输入你的gitlab主页的地址:

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.weibo.cn/

输入gitlab分配给这个runner的token

Please enter the gitlab-ci token for this runner
xxx // token

这个runner的描述:

Please enter the gitlab-ci description for this runner
[hostame] my-runner

输入runner的tag，这个是区分runner的关键:

Please enter the gitlab-ci tags for this runner (comma separated):
my-tag,another-tag

输入执行器，有很多种，比如我们的就是shell:

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
shell

可能还有别的设置，根据runner的版本不同，取默认值就行了。

Whether to run untagged builds [true/false]:
[false]:
Whether to lock the Runner to current project [true/false]:
[true]: false

启动
gitlab-runner run

好了，回去刷新gitlab ci的页面，可以看到这个runner已经启动起来了。

五、GitLab-Runner一些配置

配置文件位于（root用户安装）
/etc/gitlab-runner/config.toml
非root用户~/.gitlab-runner/config.toml（我没试，看网上别人说的）

如果有多个runner，配置都位于这个位置，其中可能需要手动配置的是runner的工作区
添加这个字段即可builds_dir="你的路径" 可参考下图

CI-Runner虽然只是一个运行时的脚本，但是为了严格控制上线质量，检测可能的异常行为，我们将他的生命周期定义为下图所示，每个公司业务场景可能不一致，下面是我们的实践：

生命周期

业务使用TS面向对象设计，使用TS的优势不言而喻，强类型检测，避免了很多低级错误；代码可读性强，后期维护方便。
CIContext贯穿生命周期整个流程，想获取任何的配置，直接取用即可，想要添加上线资源，像webpack一样把资源按配置放在Assets中即可完成上线。
在每个生命周期的开始和结束都有插件的介入，例如 beforeDeploy， afterDeploy，插件化的设计可以让CI的可扩展性变强。例如我想多上线一份资源，或者想多添加一层检查，直接添加一个或两个插件，在对应的 deforeDeploy和 beforeCheck插件运行时做处理即可。
每家的CI业务场景可能都不一致，这里只是我们的一个思路，定义明确的生命周期可以让业务变得易于维护和扩展。

Over。