一文入门Gitlab CI/CD

CI/CD是什么

CI/CD,代表持续集成(Continuous Integration)和持续交付/部署(Continuous Delivery/Continuous Deployment),是现代软件开发流程中的关键实践,旨在提高开发效率和软件质量。

  • CI(Continuous Integration)

    在遵循严格开发流程规范的项目中,开发人员向线上Git仓库提交代码时,通常会自动触发一系列操作,包括自动构建、代码规范检测和自动化测试,这些操作共同构成了持续集成的过程。

    CI的好处是可以避免不符合规范的代码提交到线上仓库,在一定程度上保证了代码的质量。

  • CD(Continuous deployment)

    在CI的基础上,CD进一步自动化了软件的发布流程或部署到生产环境的过程。

    CD的好处是可以使得软件发布/部署更高效。

GitLab提供了一套完整的CI/CD功能:PipeLine。

GitLab PipeLine基础知识

GitLab PipeLine有两个核心组件:runner和.gitlab-ci.yml文件

runner

runner是指来负责运行定义在.gitlab-ci.yml文件中的脚本和命令(CI/CD)的程序,runner有两种方式获取:

  • 使用部署在GitLab官方服务器上的runner。优点是无需配置,缺点是要钱。

  • 使用部署在私有服务器/电脑上的runner。在私有服务器上安装runner的同时,在GitLab中注册该runner,除此之外,还需配置executor具体的可参考GitLab Runner | GitLab

    优点是免费(除了服务器的钱),缺点是要手动配置。

.gitlab-ci.yml文件

.gitlab-ci.yml文件是配置GitLab CI/CD的核心,位于项目的根目录,GitLab会自动识别该文件来执行CI/CD。

Stage

在GitLab的Pipeline中,CI/CD过程被划分为多个阶段(stages),每个阶段包含了一组作业(jobs)。

阶段通过.gitlab-ci.yml文件中的stages字段定义:

yaml 复制代码
stages:
  - build
  - test
  - deploy

如上述代码所示,定义了buildtestdeploy三个阶段。定义的顺序即为执行顺序,这意味着在执行test阶段之前会先执行build ,然后再执行deploy

Job

在GitLab的Pipeline中,每个阶段(stage)可以进一步划分为一个或多个作业(jobs)。

作业是Pipeline中的基本执行单元,用于定义执行特定任务的配置:

yaml 复制代码
build_job:
  stage: build
  script:
    - echo "Building the project..."
    - build_command

如上述代码中所定义的build_job作业,包含了以下配置:

  • stage:指定该作业属于哪个阶段。
  • script:指定在执行该作业时要运行的命令列表。可以是构建命令、测试命令或任何其他shell命令。

以下是一个简单的.gitlab-ci.yml文件demo。

yaml 复制代码
stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the project..."
    - build_command

test_job:
  stage: test
  script:
    - echo "Running tests..."
    - test_command

deploy_job:
  stage: deploy
  script:
    - echo "Deploying the project..."
    - deploy_command

.gitlab-ci.yml文件进阶参数

至此,相信各位读者对GitLab的Pipeline有大致的了解,能初步读懂自己公司的.gitlab-ci.yml文件或者写写简单的.gitlab-ci.yml了,下面介绍下在配置GitLab Pipeline过程中可能会用到的进阶参数。

rules

rules定义了规则,可以与workflow和job搭配使用,常见的用法是用来定义流水线和作业的触发规则,以与workflow搭配使用为例来介绍。

workflow定义了Pipeline的行为,其可与rules参数搭配使用来定义什么情况下执行PipeLine。

yaml 复制代码
workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "api"'
    - if: '$CI_PIPELINE_SOURCE == "web"'
    - if: '$CI_PIPELINE_SOURCE == "triggers"'
    - if: '$CI_PIPELINE_SOURCE == "schedules"'

上述代码的意思是如果流水线是由以下事件之一触发,则执行PipeLine:

  • 合并请求事件(merge_request_event
  • API调用(api
  • Web操作(web
  • 触发器(triggers
  • 计划任务(schedules

CI_PIPELINE_SOURCE是gitlab预定义的变量,代表触发PIPELine的事件,api和web等值具体的意思可以参考以下资料。

Choose when to run jobs | GitLab

tags

前面讲到过GitLab pipeline的核心之一是runner,tags参数的作用是指定执行job的runner。

yaml 复制代码
build_job:
  stage: build
  tags: 
    - runner1
  script:
    - echo "Building the project..."
    - build_command

上述代码指定了build_job作业由runner1执行。

before_script:

定义在运行PipeLine前执行的命令。

yaml 复制代码
before_script:
  - chmod +x ./gradlew
  - ./gradlew clean

variables

该变量统一定义.gitlab-ci.yml需要用到的变量,其优点是方便了变量的管理。

yaml 复制代码
variables:
  GITLAB_CI_BUILD_ROOT_PATH: "gitlabci"
  GITLAB_CI_BUILD_SCRIPT_PATH: "${GITLAB_CI_BUILD_ROOT_PATH}/scripts"

当需要使用时,只需使用或者{}将变量名包裹起来,如使用GITLAB_CI_BUILD_SCRIPT_PATH时。

yaml 复制代码
- source ${GITLAB_CI_BUILD_SCRIPT_PATH}/gitlabci-envsetup.sh

其它进阶玩法具体可以参考官方文档CI/CD YAML syntax reference | GitLab

写在最后

文章到这里就结束啦,最后不得不吐槽一句GitLab的code review真难用,peace。

相关推荐
但老师3 小时前
Git遇到“fatal: bad object refs/heads/master - 副本”问题的解决办法
git
秃头女孩y3 小时前
git创建分支
git
研究是为了理解8 小时前
Git Bash 常用命令
git·elasticsearch·bash
DKPT8 小时前
Git 的基本概念和使用方式
git
Winston Wood11 小时前
一文了解git TAG
git·版本控制
喵喵先森12 小时前
Git 的基本概念和使用方式
git·源代码管理
xianwu54313 小时前
反向代理模块
linux·开发语言·网络·git
binishuaio15 小时前
Java 第11天 (git版本控制器基础用法)
java·开发语言·git
会发光的猪。16 小时前
如何在vscode中安装git详细新手教程
前端·ide·git·vscode
stewie618 小时前
在IDEA中使用Git
java·git