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。
