一文入门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。

相关推荐
Smile丶凉轩7 小时前
微服务即时通讯系统的实现(服务端)----(1)
c++·git·微服务·github
和你一起去月球16 小时前
TypeScript - 函数(下)
javascript·git·typescript
我不是程序猿儿17 小时前
【GIT】TortoiseGit的变基(Rebase)操作
git
yyycqupt1 天前
git使用(一)
git
Kkooe1 天前
GitLab|数据迁移
运维·服务器·git
Beekeeper&&P...1 天前
git bash是什么,git是什么,git中的暂存区是什么,git中的本地仓库是什么,git中工作目录指的是什么
开发语言·git·bash
Stara05111 天前
Git推送+拉去+uwsgi+Nginx服务器部署项目
git·python·mysql·nginx·gitee·github·uwsgi
lsswear1 天前
GIT 操作
git