一、CI/CD简介
CI/CD 是持续集成(Continuous Integration)和持续交付/持续部署(Continuous Delivery/Continuous Deployment)的缩写,是一种软件开发和交付的最佳实践。这两个概念通常一起使用,但有些时候它们也会被区分开来:
-
持续集成 (CI - Continuous Integration):持续集成是一种开发实践,旨在通过频繁地集成和验证代码,确保团队成员的工作不会破坏整体代码库的稳定性。在 CI 中,开发者将代码频繁地合并到共享的主干(主要分支),每次合并都会触发自动构建、测试和代码静态分析等过程。如果有问题,团队可以尽早发现并纠正。
-
持续交付 (CD - Continuous Delivery):持续交付是一种软件开发流程,旨在通过自动化构建、测试和部署的过程,使软件随时都能够交付到生产环境。持续交付的目标是确保代码在通过 CI 流程后可以随时投入生产环境,但在投入生产之前可能需要手动的最终审查和决策。
-
持续部署 (CD - Continuous Deployment):持续部署是持续交付的进一步延伸,它的目标是通过自动化流程,将通过 CI 流程的代码自动部署到生产环境,无需人工干预。在持续部署中,合格的代码经过自动测试后,将直接部署到生产环境。
CI/CD 工作流程通常包括自动化测试、构建、部署和监控等环节,以确保软件可以快速、高效地交付到最终用户手中。这对于敏捷开发、DevOps 实践以及快速响应市场需求都是非常关键的。
二、实现步骤
项目A更新代码之后通过webhook触发项目B的pipeline
1. 创建 pipeline trigger token
在需要被触发的项目的setting里面找到 Pipeline triggers,点击Add trigger 生成 token
2. 触发
当创建了token之后,可以通过API或者是webhook用 token 来触发 pipeline 事件
例如cURL:
curl --request POST \
--form token=<token> \
--form ref=<ref_name> \
"https://gitlab.example.com/api/v4/projects/<project_id>/trigger/pipeline"
CI/CD Job:
trigger_pipeline:
stage: deploy
script:
- 'curl --fail --request POST --form token=$MY_TRIGGER_TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/123456/trigger/pipeline"'
rules:
- if: $CI_COMMIT_TAG
environment: production
WebHook:Webhook(网络挂钩)是一种用于实时事件通知的机制,它允许一个系统将事件信息发送到另一个系统。Webhook 是在特定事件发生时自动触发的 HTTP POST 请求。通常,Webhook 被用于将实时事件从一个系统推送到另一个系统,从而触发自动化的操作。
https://gitlab.example.com/api/v4/projects/<project_id>/ref/<ref_name>/trigger/pipeline?token=<token>
我们这里使用 WebHook来触发项目B的自动更新事件:在项目A的设置里找到 Webhooks 填入 pipeline trigger 中获得的 url,选择相应的触发事件,下图选择了 Push 操作来触发自动更新错误码文档。
3. 创建和运行 pipeline
自动更新文档需要运行代码,这里需要我们首先有一个 runner
GitLab Runner 是 GitLab CI/CD(持续集成/持续交付)系统的一个组件,用于执行构建、测试和部署作业。Runner 负责接收来自 GitLab CI 的作业请求,并在指定的环境中执行这些作业。每个 Runner 都与一个特定项目相关联,并负责处理该项目的 CI/CD 工作。
mac下载 GitLab Runner:
brew install gitlab-runner
注册:这一步需要注意设置了tag后续ci文件里要指定tag
gitlab-runner register
启动:
gitlab-runner install
gitlab-runner start
4. 编写.gitlab-ci.yml 文件
.gitlab-ci.yml
是 GitLab CI/CD 配置文件,用于定义项目的 CI/CD 流程。这个文件应该位于项目的根目录,并包含了构建、测试、部署等阶段的定义。
以下是一个简单示例:
stages:
- build
- test
- deploy
variables:
# 定义全局变量,可以在整个文件中使用
GIT_STRATEGY: clone
TEST_IMAGE: "alpine:latest"
before_script:
# 所有阶段执行前都会执行的脚本
- echo "Before script: Initialize environment"
build_job:
stage: build
script:
- echo "Building the project..."
test_job:
stage: test
script:
- echo "Running tests..."
only:
- master # 只有在 master 分支上触发
deploy_job:
stage: deploy
script:
- echo "Deploying to production..."
only:
- master
上述示例文件定义了三个阶段(build
、test
、deploy
),并定义了一些全局变量。每个阶段下都有一个或多个作业(job
)的定义,包括作业的名称、阶段、脚本等信息。
before_script
: 定义了在所有阶段执行前都会运行的脚本。build_job
: 定义了一个构建作业,用于构建项目。test_job
: 定义了一个测试作业,用于运行测试。通过only
关键字,指定只有在master
分支上触发时才执行。deploy_job
: 定义了一个部署作业,用于将项目部署到生产环境。同样,通过only
关键字,指定只有在master
分支上触发时才执行。
自动更新操作:
stages:
- run_main_go
run_main_go:
stage: run_main_go
image: reg.smvm.cn/appbase/golang-build:1.21-alpine3.17
script:
- go mod download -x
- go run main.go
artifacts:
paths:
- "*.md"
tags:
- k8runner
项目A的Push事件都会触发项目B的自动更新文档操作