gitlabCI持续集成的总结（gitlab+gitlabCI）

最新推荐文章于 2024-07-07 12:53:35 发布

longG_It

最新推荐文章于 2024-07-07 12:53:35 发布

阅读量1k

点赞数

本文链接：https://blog.csdn.net/qq_41166135/article/details/104559040

版权

**重点提醒：踩了太多的坑，建议直接在centOS7.x版本上安装运行
1.首先安装一下gitlab，有详细亲测有效的教程：https://www.cnblogs.com/zhangycun/p/10963094.html
2.安装gitlab Runner，有详细亲测有效的教程：https://blog.csdn.net/qq_27520051/article/details/80552220
3.个人总结：
1.持续集成相关概念
1.1 什么是持续集成
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
自动化的构建、测试和部署流程可以解决软件开发项目中的许多麻烦和问题。通过可靠的方法频繁整合代码更改，可以尽早发现错误。毕竟没有人希望在demo day出现由于几个月前编写一直没有适当的机会进行合理测试而出现的任何差池。
1.2 持续集成的流程
持续集成的流程根据持续集成的设计，代码从提交到生产，整个过程如下：
 开发者向仓库提交代码
 检测到代码提交后，进行构建(build)。构建的目的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源(样式表、JS脚本、图片)等等。
 只要检测到有提交代码或者合并，自动跑模块单元测试。

 构建完成，就要进行第二轮测试。第二轮是全面测试，单元测试和集成测试都会跑，所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。
 通过了第二轮测试，形成测试通过的版本，部署到生产服务器

1.3 持续集成的好处
首先，降低集成风险。多数情况下，一个项目会有多个人单独处理任务或者一部分代码，人员越多，整合的风险越大，而调试、解决问题本身会是非常痛苦的，我们很可能需要大量修改代码。频繁的集成将极大减少此类问题。
第二，保障代码质量。我们可以把精力放在业务代码和功能上，从而获得更高质量的软件。
第三，有效的版本控制。如果有人提交的代码有问题，团队会即时收到通知，在有任何人拉取之前解决问题。
第四，减少团队间摩擦。明确而公正的制度流程可以减少团队之间的争吵。
第五，改善测试团队生活质量通过不同版本和构建隔离并追踪错误可以有效减轻测试团队负担。
第六，部署更快。自动化可以让原本繁琐耗时的部署工作变得轻松高效。
第七，增强团队信心和士气。团队成员不必再为潜在错误可能会造成的不良后果而忧心忡忡，可以轻装上阵去创造更好的软件。
1.4 持续集成的要求
全面的自动化测试。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要；
灵活的基础设施。容器，虚拟机的存在让开发人员和 QA 人员不必再大费周折；
版本控制工具。如 Git，CVS，SVN 等；
自动化的构建和软件发布流程的工具，如 Jenkins，gitLab.ci；
反馈机制。如构建/测试的失败，可以快速地反馈到相关负责人
1.5 持续集成服务器
持续集成服务器（也称为构建服务器，又称CI服务器）是一种软件工具，它包含所有持续集成操作，并为我们构建项目提供可靠和稳定的环境。一般持续集成服务器具备高度可配置性和可调整性，能够为不同平台构建各种项目。
使用持续集成服务器最好能够安装在干净的机器上，保证其在中立的环境中不受不必要的工具、环境变量和其他配置影响。如果实在没有物理机，可以考虑构建一个虚拟环境。
持续集成服务器通常使用版本控制系统（如Subversion或Git或任何其他版本）来提取项目文件。该系统监控项目仓库，在代码成功提交时，会拉去更改并按照我们的定义来执行。完成任务后，持续集成服务器会向相关成员发送构建细节信息。检查项目的最新版本、运行构建脚本、运行测试以及发送通知是持续集成服务器的最基本功能。
除此之外，代码分析、代码覆盖率、代码质量报告、agent pooling、pipeline、构建比较、IDE集成、第三方工具支持等功能，会让持续集成服务器更加灵活好用。
1.6 对于团队的要求
相比硬件、软件或者工具，人的因素对于持续集成成功与否更为关键，这要求团队里的每个成员都能养成良好的“持续集成”习惯，例如频繁提交代码、立即修复失败构建、编写单元测试等等。
2.持续集成，该从何入手
2.1持续集成系统的选择
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统，关键在于团队运行的基础设施，团队对持续集成系统的资源投入力度。另外，在选择合适的持续集成服务时，还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
通过持续集成，及时发现和解决代码故障，提高代码质量，减少故障处理成本等等。当下持续集成工具不胜枚举，开源的或商业的，可本地安装的或Sass的，如：
当前最最流行的，一骑绝尘的Jenkins
1.与Github紧密集成的Travis CI
2.有着持续集成DNA的ThoughtWorks GO
3.Atlassian工具链之一的Bamboo
4.与Gitlab紧密集成的Gitlab CI
2.2Jenkins和Gitlab CI的相比较
目前与我们关系比较密切且比较受欢迎的两种是Jenkins和Gitlab CI,
持续集成工具技术选型（Jenkins VS Gitlab CI）：
1.Jenkins有GUI，GUI使得易于学习与使用，但一系列插件可能会变得混乱不堪，如果需要用户访问与管理，这个是首选。
2.与Gitlab的集成，Jenkins不及Gitlab CI，Jenkins需要为Project创建JOB，commit与build对应关系无法直观体现。
3.Gitlab CI有漂亮的界面，每个构建有迹可循，偏于回溯，使用yaml定义Build Pipeline更清晰。
鉴于我们现在用的是Gitlab,以及Gitlab CI与Gitlab集成的更友好，于是选择了Gitlab CI做持续集成。
3. Gitlab CI持续集成
3.1 Gitlab CI简介
gitlab-ci全称是gitlab continuous integration的意思，也就是持续集成。中心思想是当每一次push到gitlab的时候，都会触发一次脚本执行，然后脚本的内容包括了测试，编译，部署等一系列自定义的内容。

3.2 Gitlab CI流程
1.代码Check In到GitLab
2.提交后触发Gitlab CI（使用Docker进行Build,一定得使用CentOS7.X版本的镜像才可以安装Docker）
3.Gitlab CI 拉取代码进行编译、质量分析（SonarQube ）
4.SonarQube 将质量分析报告反馈到GitLab相应的commit（以Comment的形式）
5.Gitlab将构建结果反馈给Develop （以Email的形式）
3.3 Gitlab CI原理
GitLab CI 是GitLab内置的进行持续集成的工具，只需要在仓库根目录下创建.gitlab-ci.yml 文件，并下载、配置GitLab Runner；每次提交的时候，gitlab将自动识别到.gitlab-ci.yml文件，并且使用Gitlab Runner执行该脚本。

Gitlab CI自动部署涉及了若干个角色，主要介绍如下：
GitLab-CI
这个是一套配合GitLab使用的持续集成系统，是GitLab自带的，也就是你装GitLab的那台服务器上就带有的。无需多考虑。.gitlab-ci.yml的脚本解析就由它来负责。
GitLab-Runner
GitLab-Runner就是一个用来执行.gitlab-ci.yml 脚本的工具。可以理解成，Runner就像认真工作的工人，GitLab-CI就是管理工人的中心，所有工人都要在GitLab-CI里面注册，并且表明自己是为哪个项目服务。当相应的项目发生变化时，GitLab-CI就会通知相应的工人执行对应的脚本。这些脚本有的是测试项目用的，有的是部署用的。

Runner类型
GitLab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。
Shared Runner：所有工程都能够用的，且只有系统管理员能够创建。
Specific Runner：只有特定的项目可以使用。

gitlab-ci.yml
这个是在git项目的根目录下的一个文件，记录了一系列的阶段和执行规则。GitLab-CI在push后会解析它，根据里面的内容调用runner来运行。
3.4相关概念
管道（pipeline）
每个推送到 Gitlab 的提交都会产生一个与该提交关联的管道(pipeline)，若一次推送包含了多个提交，则管道与最后那个提交相关联，管道(pipeline)就是一个分成不同阶段(stage)的作业(job)的集合。
阶段（Stage）
阶段是对批量的作业的一个逻辑上的划分，每个 GitLab CI/CD 都必须包含至少一个 Stage。多个 Stage 是按照顺序执行的，如果其中任何一个 Stage 失败，则后续的 Stage 不会被执行，整个 CI 过程被认为失败。
以图中所示为例，整个 CI 环节包含三个 Stage：build、test 和deploy。

build 被首先执行。如果发生错误，本次 CI 立刻失败；
test 在 build 成功执行完毕后执行。如果发生错误，本次 CI 立刻失败；
deploy 在 test 成功执行完毕后执行。如果发生错误，本次 CI 失败。
下图是Gitlab对阶段和阶段状态的展示：

作业（Job）
作业就是运行器(Runner)要执行的指令集合，Job 可以被关联到一个 Stage。当一个 Stage 执行的时候，与其关联的所有 Job 都会被执行。在有足够运行器的前提下,同一阶段的所有作业会并发执行。作业状态与阶段状态是一样的，实际上，阶段的状态就是继承自作业的。
作业必须包含script（由Runner执行的shell脚本），随着项目越来越大，Job 越来越多，Job 中包含的重复逻辑可能会让配置文件臃肿不堪。.gitlab-ci.yml 中提供了 before_script 和 after_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。
Job 的执行过程中往往会产生一些数据，默认情况下 GitLab Runner 会保存 Job 生成的这些数据，然后在下一个 Job 执行之前（甚至不局限于当次 CI/CD）将这些数据恢复。这样即便是不同的 Job 运行在不同的 Runner 上，它也能看到彼此生成的数据。
在了解了 Job 配置的 script、before_script、after_script 和 cache 以后，可以将整个 Job 的执行流程用一张图概括：

创建.gitlab-ci.yml 文件
什么是.gitlab-ci.yml文件
从7.12版本开始，GitLab CI使用YAML文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录，并且包含了你的项目如何被编译的描述语句。YAML文件使用一系列约束叙述定义了Job启动时所要做的事情。
Job
Job是.gitlab-ci.yml文件中最基本的元素，由一系列参数定义了任务启动时所要做的事情，用户可以创建任意个任务；每个任务必须有一个独一无二的名字，
但有一些保留keywords不能用于Job名称，image，services，stages，types，before_script，after_script，variables，cache。
Job被定义为顶级元素，并且至少包括一条script语句，如果一个 Job 没有显式地关联某个 Stage，则会被默认关联到 test Stage。
示例：

管道参数详情
下面是关于配置CI/CD管道的常用参数详细说明。
stages
用于定义所有作业(job)可以使用的全局阶段，gitlab-ci.yml允许灵活定义多个阶段，stages元素的顺序定义了作业执行的顺序。Job关联的stage名相同时，该多个Job将并行执行（在拥有足够Runner情况下）。下一个阶段的job将会在前一个阶段的job都完成的情况下执行。
如果文件中没有定义 stages，那么则默认包含 build、test 和 deploy 三个 stage。Stage 中并不能直接配置任何具体的执行逻辑，具体的执行逻辑应该在 Job 中配置。
示例：

stage
阶段是根据每个Job定义的，并且依赖于全局定义的阶段。它允许将作业(Job)分组到不同的阶段。

script
script是一段由Runner执行的shell脚本。
示例：

这个参数也可以使用数组包涵好几条命令：

有些时候，script命令需要被单引号或者双引号所包裹。举个例子，命令中包涵冒号的时候，该命令需要被引号所包裹，这样YAML解析器才知道该命令语句不是“key: value”语法的一部分。当命令中包涵以下字符时需要注意打引号:: { } [ ] , & * #? | - < > = ! % @ `

image and services
这两个选项允许开发者指定任务运行时所需的自定义的docker镜像和服务。

before_script和after_script
before_script是用于定义一些在所有任务执行前所需执行的命令, 包括部署工作，可以接受一个数组或者多行字符串。after_script用于定义所有job执行过后需要执行的命令，可以接受一个数组或者多行字符串。
示例：

only and except
only和except两个参数说明了job什么时候将会被创建：
only定义了job需要执行的所在分支或者标签
except定义了job不会执行的所在分支或者标签
以下是这两个参数的几条用法规则：
only和except如果都存在在一个job声明中，则所需引用将会被only和except所定义的分支过滤
only和except允许使用正则
only和except允许使用指定仓库地址，但是不forks仓库
此外，only和except允许使用以下一些特殊关键字：

3.5 详细步骤
3.5.1安装GitLab-CI
这个不用安装了，装好GitLab就自带了
3.5.2 安装GitLab-Runner
在centOS上安装gitlab-ci-multi-runner（内网不能互联网下载，需要安装包）
#首先下载安装包
$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
#接着授予可执行权限
$ sudo chmod +x /usr/local/bin/gitlab-runner
#创建一个gitlab-ci用户
$ sudo useradd --comment ‘GitLab Runner’ --create-home gitlab-runner --shell /bin/bash
#安装，并作为服务启动
$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
这样就装好了gitlab-ci-multi-runner。
然而我们只是装好了gitlab-runner，我们如何知道gitlab-CI的runner（工人）是为谁服务呢？所以我们要接着向gitlab-CI注册这个runner，这样就知道了gitlab-CI在push事件到来的时候要调用谁。
3.5.3 注册Runner
 可根据需求注册选择所需类型Runner。（一种是公用的一种是特殊的）
 使用管理员用户登录，进入Admin Area->OverView->Runners界面。
 获取Specific Runner注册Token：
 进行项目仓库->settings->CI/CD界面
 执行gitlab-runner register命令进行Runner注册，期间会用到前期获取的url及token：
$ gitlab- runner register#引导会让你输入gitlab的url，输入自己的url，例如http://gitlab.example.com/#引导会让你输入token，去相应的项目下找到token，例如ase12c235qazd32#引导会让你输入tag，一个项目可能有多个runner，是根据tag来区别runner的，输入若干个就好了，比如web,hook,deploy#引导会让你输入executor，这个是要用什么方式来执行脚本，图方便输入shell就好了。
注册完成之后，GitLab-CI就会多出一条Runner记录：
3.5.4编写.gitlab-ci.yml
在项目根目录下编写.gitlab-ci.yml这样在push之后，gitlab-ci就会自动识别来解析了。
#所有的任务执行阶段，前一个成功才会执行下一个阶段的任务，同一个阶段的任务可以同时执行
stages: