GitLab CI/CD 入门与简单实践

GitLab CI/CD 入门与简单实践

本文提供了 GitLab CI/CD 的入门操作介绍，分享了一些零基础学习使用 GitLab 进行 CI/CD 过程的经验。
在学习 GitLab CI/CD 之前，我们先来了解一下 CI/CD 的含义，以便于在做到在心中有数的前提下高效的进行学习：
CI/CD 代表一种软件开发和交付的实践方法，其具体含义如下：

1. 持续集成（Continuous Integration, CI）：

   • 持续集成是指开发人员频繁地将代码提交到共享的代码仓库，并通过自动化的构建、测试和静态分析等流程，来尽早发现和解决集成问题，确保代码的稳定和可靠性。

2. 持续交付（Continuous Delivery, CD）：

   • 持续交付意味着确保软件能够随时处于可交付状态，可以通过自动化流程进行快速、可靠的部署到生产环境中，以满足用户需求并降低部署风险。

3. 持续部署（Continuous Deployment, CD）：

   • 持续部署是持续交付的延伸，指的是自动将通过持续集成和持续交付流程生成的软件包部署到生产环境，并减少人工干预，实现全自动化的部署流程。

因此，完整的CI/CD（持续集成/持续交付/持续部署）方法旨在通过自动化的工作流程实现软件开发、测试和交付的快速、持续和高质量。此方法使团队能够频繁地集成和交付软件，并通过持续部署实现自动化的部署流程，从而更快速地满足用户需求。
接下来，我们将从why，what，how三个角度来讲述 GitLab CI/CD，本篇文章主要侧重于如何操作，所以how(怎么做)这个环节的讲诉会较为详细。

为什么选择使用 Gitlab CI/CD 工具进行CI/CD过程?

选择使用 GitLab CI/CD 工具进行 CI/CD 过程有以下几个主要原因：

1. 集成性：GitLab CI/CD 是 GitLab 自家提供的一体化 CI/CD 解决方案，与 GitLab 代码仓库无缝集成。这意味着你可以在同一个平台上管理代码、发起合并请求、进行持续集成和部署。集成性使得团队可以更高效地进行软件开发和交付流程，减少了不同工具之间的对接问题。

2. 开源和自托管：GitLab CI/CD 是开源的，这意味着你可以自由获取、修改和定制使用。你可以根据自己的需求进行部署和配置，完全掌握 CI/CD 过程的控制权。同时，GitLab 也提供了自托管的选择，你可以将 GitLab 部署在自己的服务器或云环境中，对保密性和隐私性有更高的要求的组织可以选择自行管理。

3. 强大的功能和扩展性：GitLab CI/CD 提供了丰富的功能，包括自动化构建、测试、部署、持续交付、容器编排等。你可以通过在 .gitlab-ci.yml 文件中定义作业和阶段的方式，非常灵活地定制和扩展 CI/CD 流程。另外，GitLab CI/CD 还与 GitLab 的其他功能紧密集成，如问题追踪、代码审核、容器注册表等，提供了完整的开发和交付工具链。

4. 广泛的生态系统支持：GitLab CI/CD 作为一种常用的 CI/CD 工具，有庞大的社区和生态系统支持。你可以通过 GitLab 官方文档、社区论坛和开发者社区获取帮助和支持。另外，GitLab CI/CD 还与其他开源工具和云平台集成，如 Kubernetes、Docker、AWS、Azure 等，提供了更广泛的选择和集成能力。

5. 可视化和易用性：GitLab CI/CD 提供了直观的可视化界面，让你可以方便地查看和管理流水线的执行结果、日志和部署状态。同时，GitLab CI/CD 的配置文件也采用了易读易写的 YAML 格式，使得编写和维护 CI/CD 流程变得更加简单和可维护。

综上所述，选择使用 GitLab CI/CD 工具可以帮助团队在同一个平台上统一管理代码仓库和持续交付流程，具有开放性、灵活性和可定制性。它提供了丰富的功能和生态系统支持，使得团队能够高效地构建、测试和部署软件，从而提高开发效率和交付质量。

GitLab CI/CD 是什么?

当谈论 GitLab CI/CD 时，它是 GitLab 提供的一套集成的持续集成和持续交付工具。它集成到了 GitLab 的版本控制系统中，为团队提供了一种简单而强大的方式来自动化构建、测试和部署软件。简单来说，它主要具有以下几个特性:

1. 良好的用户体验
2. 部署覆盖场景广
3. 运行足够快，且支持并行构建
4. 多平台支持
5. 开源免费
6. 操作流程较为简单，可快速上手

GitLab CI/CD 的基本概念

GitLab CI/CD 由两部分构成:

1. GitLab Runner 提供的运行流水线的环境
2. 定义流水线内容的.gitlab-ci.yml文件

另外，当使用 GitLab CI/CD 时，流水线（Pipeline）、阶段（Stages）和作业（Jobs）是其中重要的概念。

1. 流水线（Pipeline）：流水线是一系列相互关联的自动化操作，用于构建、测试和部署软件。在 GitLab CI/CD 中，每次代码提交或者其他触发条件满足时，会创建一个新的流水线。流水线可以包含多个阶段和作业，代表了一次完整的构建、测试和部署过程。
2. 阶段（Stages）：阶段是流水线中的逻辑分组，用于将作业分组并定义它们的执行顺序。通常，一个流水线包含多个阶段，比如构建（Build）、测试（Test）和部署（Deploy）等。每个阶段可以包含一个或多个作业，它们的执行是有序的，一般情况下后一个阶段的作业依赖前一个阶段的作业。
3. 作业（Jobs）：作业是流水线中的最小执行单元，代表了实际需要执行的任务。作业定义了需要执行的命令、环境配置、依赖关系等。在 GitLab CI/CD 中，一个流水线通常包含多个作业，比如构建代码、运行单元测试、部署到测试环境等。
4. 它们之间的关系：一个流水线包含多个阶段，每个阶段包含一个或多个作业。阶段之间的作业执行是有序的，一个阶段的作业完成后才会执行下一个阶段的作业。而在同一个阶段内，作业可以并行执行，以加快整个流水线的执行速度。通过这样的逻辑关系，可以实现复杂的构建、测试和部署流程，并方便地管理和监控整个过程。

如何使用 GitLab CI/CD?

接下来，我们将讲诉如何搭建 GitLab CI/CD 的环境以及提供一个简单的流水线实操示例。

搭建 GitLab CI/CD 环境

由于 GitLab CI/CD 的运行环境就是由 Gitlab Runner 提供的，因此搭建其环境的过程其实就是安装与注册 Gitlab Runner 的过程。
考虑到本人仅仅学过使用Linux系统进行 Gitlab CI/CD 环境的搭建，因此这里直接分享 Gitlab 的官方文档:
安装 GitLab Runner
注册 GitLab Runner
如果你使用的并非公司已经搭建好的 Gitlab 远程仓库，则可以按照这篇文章使用Linux系统搭建个人仓库(并且这篇文章还提供了个人仓库中本地仓库与远程仓库的交互所用的git指令):
Gitlab仓库搭建
若需要详细学习git,则可查阅 GitLab 官方文档:
学习Git

注册 GitLab Runner 注意事项

1. 项目信息查看位置:点击你的 GitLab 项目页面的左侧栏的 Settings 选项，再点击 Settings 下的 CI/CD 选项，找到并点击 Runners 选项，其中 Specific runners 栏目下就包含着你的项目的 URL 以及 registration token 信息，在为你的特定项目注册 runner 时，就输入对应信息即可。如果想要在不同项目下共享使用一个 runner ，则可以注册共享 runner ，这个可在 Runners 选项下的 Shared runners 栏目下查看对应文档进行。(一般来说为了避免冲突等考虑，不推荐一个 runner 在不同项目下进行共享使用，相反地，一个项目通常会使用多个 Spacific runner 进行流水线的执行)
2. runner 执行器的选择:在注册 GitLab Runner 时，执行器（Executor）的选择是根据需求和限制来决定的。不同的执行器具有不同的特点和适用场景。下面是几种常见的执行器选项及其特点：

执行器	描述	适用场景
Shell	Shell 执行器简单且轻量，是通过 shell 命令来执行 CI/CD 作业的执行器。它不需要依赖其他工具，在大多数 Linux/Unix 环境中都可用。它可以直接依靠注册 runner 的主机环境来执行脚本操作，因此可以不需要安装重复的依赖项，操作较为简便。	简单的构建和部署任务，不需要额外的工具依赖
SSH	SSH 执行器通过 SSH 协议远程连接到服务器并执行作业。它可以在远程主机上执行构建、测试和部署任务。	运行需要远程访问的作业，如在特定服务器上构建应用
Docker	Docker 执行器在容器中运行作业。它会启动一个专用的 Docker 容器，然后在容器内运行作业。	构建、测试和部署在 Docker 容器中的应用程序
Kubernetes	Kubernetes 执行器在 Kubernetes 集群上启动一个 Pod，并在 Pod 内运行作业。	在 Kubernetes 上运行构建、测试和部署任务
VirtualBox	VirtualBox 执行器在虚拟机（VirtualBox）中运行作业。	在虚拟机环境中运行构建、测试和部署任务
Docker-Machine	Docker-Machine 执行器在远程主机上启动一个 Docker 容器，并在容器内运行作业。	运行需要在远程主机上执行的 Docker 作业

选择执行器时，需要考虑以下因素：

1. 环境需求：执行器是否满足所需的操作系统、软件依赖等环境需求，以确保可以顺利运行作业。

2. 安全性：执行器是否具备足够的安全性，特别是在需要访问私密信息或与敏感数据相关的作业中。(其中，shell执行器并不会阻止runner访问整个主机的文件系统，安全性最低，须谨慎使用。其他的执行器虽然不允许runner 访问整个文件系统，但也可能由于某些特殊的配置跳出容器从而访问 runner 的宿主机文件系统，也需注意其安全隐患 )

3. 执行可靠性与速度：执行器的执行性能和效率是否满足项目的需求，确保作业可以在合理的时间内完成。

4. 系统资源消耗：不同的执行器对系统资源的消耗程度有所不同，根据服务器的资源限制和预算考虑选择合适的执行器。

总体而言，选择适合的执行器需要综合考虑项目需求、系统资源、安全性和效率等因素，以确保作业的顺利执行和达到预期的效果。

检查 runner 是否打开且可用

查看和编辑 runner 可在 runners 下的 Available specific runners 栏目下进行。

其中出现绿色标识代表此 runner 可用，中间的黑字代表此 runner 的描述，下方的蓝色高亮表示该 runner 的标签，当进行流水线作业时，通常需要指定所用 runner 的标签。
一般来说刚注册完 runner 时并不会直接显示绿色标签，需要点击那个铅笔图案对其进行编辑(打开编辑后即可自行观察根据所需进行更改)，编辑完成后点击保存修改，然后再查看 runner 状态，若出现绿色表示则代表 runner 可用，若不出现，则继续更改并保存直至出现绿色标识。
另外，需要激活 runner 所依赖的宿主机注册 runner 时所用的环境才能正常完成流水线工作(job)的配置进程，若不激活此环境，则 GitLab CI/CD无法进行流水线工作。

从一个简单的流水线实例认识 GitLab CI/CD 操作过程

这是我的仓库中的main主分支的内容，在项目页面的 Repository 栏目下可点击 Branches 来查看和管理此项目的分支。

我将使用 GitLab CI/CD 工具进行流水线工作，这包括了构建(build)，测试(test)以及部署(deploy)三个阶段，由于本人暂且没有部署的需求，因此部署阶段只设计了让其输出信息。
.gitlab-ci.yml文件

#绿色高亮显示的部分即为关键词,#标识的即为注释
stages:    #声明此流水线所包含的所有阶段及其顺序
  - build
  - test
  - deploy
build_job: #以一个变量名开头并标注了stage，则此段落为一个job
  stage: build #标记此job属于stage阶段
  #image: gcc:latest
  before_script:  #before_script关键词指定了在脚本script之前进行的操作
    - echo "This command before script"
  #image:关键词可指定该作业选用镜像(一般为编译器镜像)
  script:  #script指定了脚本操作，对于shell执行器而言此脚本操作即为在命令行进行操作
    - rm -rf build    #若存在build文件夹则将其删除
    - cmake -B build  #使用Cmake构建build目录
    - cmake --build build #使用Cmake进行编译指令
    - echo "This is build" #在日志中输出信息 "This is build"
  artifacts:   #指定了保存此job的生成文件
    paths:   #指定保存路径
     - ./build          #只要设定保存到当前目录下即可
    #由于创建的build目录与保存路径名字均为build，因而创建的build文件夹会直接覆盖build路径而不会出现build文件夹下还有一个build文件夹的情况
    #keep:true   保存指令,打开了此构建文件会保留至下一个流水线开始之前
    #download:true 可供其他job下载
    #browse:true   可直接从浏览器页面浏览
  after_script: #script之后执行的脚本操作
    - echo "This command after script"
  tags:
    - ex  #指定该job使用标签为ex的runner进行操作
build_job2:  #此job用于展示一个阶段可以包含多个工作(job)
  stage: build
  script:
    - echo "This is the second build job"
  tags:
    - ex
test_job:
  stage: test   #测试阶段
  #image: gcc:latest
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - ./build/Project1  #调用build_job工作构建的build目录下的Project1可执行文件进行一个简单的测试
    #Project1会输出当前系统时间，可人为观察其结果是否正确
    #严格来说这并不属于严谨的测试，严谨的测试比如单元测试这些需要对应的框架来执行，且若测试出错也会自动地导致测试阶段失败
  #dependencies:
    #- build_job            #若build_job打开了download:true，则会下载其用paths保存的文件
  tags:
    - ex
deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."  #好像因为权限问题不能自己推送到自己仓库
  #environment指定部署作业的环境名称
  environment: production    #testing 测试环境,production 正式环境
  #dependencies:
    #- build_job
  tags:
    - ex

这里直接点击 CI/CD 栏目下的 Pipelines ，在右上角点击 Run pipelines 来触发流水线进程。当然，修改.gitlab-ci.yml文件，直接修改、增添远程仓库项目内容，合并请求等操作也会自动触发流水线。

可在项目页面的 CI/CD 栏目下点击 Pipelines 查看对应的流水线状况，此流水线状况如图所示

可以在 CI/CD 栏目下点击 Jobs 查看各个 job 的状态

点击它们的蓝色标亮名字即可查看该 job 的工作日志

在本地修改项目内容并提交合并请求并进行合并示例

这里提供了一个简单的示例，演示了如何从本地新建分支并拉取远程仓库主分支，再对此新建分支进行修改后上传远程仓库，然后提交合并请求，接着仓库管理者对合并请求进行检查后通过进行合并操作并触发流水线的过程。

设置合并前源分支必须先通过流水线

在进行示例之前，我们先设置一个选项，来对合并请求的源分支的流水线状态进行检查，这样做的目的是确认在合并操作之前源分支的流水线能够成功。尽管在进行合并操作的时候会自动流水线，但一旦合并操作被通过，main主分支的.gitlab-ci.yml文件会被替换为合并请求源分支的.gitlab-ci.yml文件，因此，若请求者对.gitlab-ci.yml文件进行了修改，而此修改恰好会导致流水线进程的失败的情况下，应先对源分支进行一次流水线用以判断，确保其流水线处于成功状态，避免其在流水线不通过的状态(源分支在这种状态下向主分支合并是一种较为危险的情况)进行合并操作。
我们点击项目页面的 Settings 栏目，在 General 选项下会有一个 Merge requests 选项，点击其右侧的 Expand 按钮，往下翻找到这个选项：

默认情况下是不勾选的，我们将其勾选即可完成设置。

从本地进行修改并提交合并请求

当然，若想完成这一步，得先设置 GitLab 免密登录的公私钥配对，具体操作过程在如下的博客第十章：Gitlab仓库搭建
转到本地主机环境，创建一个新目录并进入其中，打开终端命令行，逐行输入以下指令:

git init    #git初始化该目录
git remote add origin Yourprojectssh    #这里输入你的项目的SSH
#git remote 用以建立远程仓库与本地仓库的联系

项目的SSH密钥以git开头，可在项目仓库主页右上角点击 Clone 按钮获取

接着输入:

git checkout -b update  #创建一个名为update的本地分支并进入其中
git pull origin main    #拉取远程主分支内容

然后便可进行修改，我这里创建了一个新的文本文件update.txt

然后输入:

git add .                    #添加本目录下所有文件到暂存区
git commit -m "update main"  #提交更改至本地仓库
#任何一次修改都必须提交至本地仓库,否则将无法上传远程仓库
git push -u origin update    #在远程仓库创建分支update并与本地仓库关联并上传本地仓库对应文件

此时你的远程仓库便会出现对应的新分支update。
但这时候进入项目主页面查看项目分支可能会发现一个问题(若未出现此问题可跳过此过程):

那就是新添加的这个update分支并未显示Merge request按钮，这其实是仓库的注册表可能出了问题，远程仓库并未真正存储此分支。解决办法就是新建一个分支，点击右上角的 New branch 按钮直接创建新分支

然后点击创建即可
这时候会自动触发流水线进程，然后流水线完毕后，可以看到 update 分支右侧就出现了和其他分支一样的 Merge request 按钮，这时候即恢复正常了。
未出现上诉问题跳至此处继续

可以看到新传入的 update 分支右侧有个 Merge request 按钮，点击它，然后输入好对应的标题和内容点击创建合并请求即可:

管理员通过合并请求并完成合并的过程

这时候管理员会在 Merge requests 处收到一个合并请求:

黄色标注的地方即为源分支的流水线情况，我这里是已经成功完成流水线因而会出现绿色的勾代表流水线已经完成，若未完成流水线，则此处会出现一个检测流水线状态的圆圈，此时管理员需要点击 CI/CD 栏目，选择右上角的 Run Pipelines ，并选择此新提交的源分支触发其流水线进程，等待流水线完成之后才会出现 Merge 按钮。
管理员可以审核一下此请求的内容，可点击上面的 Open in Web IDE 与主分支进行对比查看其修改内容，确认无误后可以点击 Approve 按钮和 Merge 按钮，当按下 Merge 按钮后，会触发合并操作的流水线进程:

若成功，则会实现对主分支的更改，若失败，则不会进行文件的更改。(但无论merge流水线成功与否，main主分支的.gitlab-ci.yml文件会与合并的源分支update内的.gitlab-ci.yml同步)
流水线成功

此时main主分支确认出现更改(即新增update.txt文件)

这样，就实现了操作人员对远程仓库项目的更新工作，并通过测试来保证此更新的稳定性(此演示的测试步骤并不严谨，但实际操作可自行依据测试框架更改)。
如果是软件的更新迭代，则须设定好对应的部署阶段，确保更新完成后内容被部署到目标环境可供用户使用。