CI/CD 入门：从代码提交到自动部署，彻底搞懂现代项目发布流程

做开发一段时间之后，你一定会遇到这些词：

Jenkins
GitLab CI
GitHub Actions
Pipeline
CI
CD
Docker
Kubernetes
DevOps
自动构建
自动部署
流水线

刚开始很容易觉得这些东西特别乱。

实际上，它们都围绕一个非常核心的问题：

开发人员写完代码以后，怎么让代码安全、稳定、快速地跑到服务器上？

CI/CD 就是在解决这件事情。

可以先记住一句最简单的话：

CI/CD
=
让“代码提交 → 测试 → 构建 → 部署”
尽可能自动化

一、没有 CI/CD 的项目是怎么发布的？

先不要急着看 CI/CD。

先想一下，如果完全没有自动化，一个 Java 项目怎么上线？

假设我们有：

Spring Boot
+
MySQL
+
Redis

开发人员写完代码以后，可能要手动：

git pull

mvn clean package

java -jar xxx.jar

甚至还要：

登录服务器

停止老项目

备份 jar

上传新 jar

修改配置

启动项目

查看日志

完整流程可能是：

开发写代码
    ↓
Git 提交代码
    ↓
人工拉取代码
    ↓
人工执行 Maven 打包
    ↓
人工测试
    ↓
人工上传 jar
    ↓
人工登录服务器
    ↓
停止旧服务
    ↓
启动新服务
    ↓
检查日志

如果一个月发布一次，可能还能忍。

但是如果：

每天发布 5 次

或者：

几十个微服务
几十个开发人员
多个测试环境
多个生产环境

人工发布会变得非常痛苦。

二、人工发布有什么问题？

最明显的问题就是：

容易出错

例如开发人员忘了：

执行测试

或者忘了：

切换生产配置

或者：

上传错 jar

甚至：

A 同事本地 JDK 17

B 同事服务器 JDK 11

结果：

本地运行正常

服务器启动失败

还有一种经典情况：

“我本地明明是好的！”

因此，软件工程逐渐希望：

把这些重复操作交给机器

于是 CI/CD 出现了。

三、CI/CD 到底是什么意思？

CI/CD 通常拆成：

CI

CD

其中：

CI
=
Continuous Integration
=
持续集成

而 CD 可能表示：

Continuous Delivery
持续交付

或者：

Continuous Deployment
持续部署

它们虽然名字接近，但含义并不完全相同。

四、什么是 CI？

CI：

Continuous Integration

中文叫：

持续集成

它最核心的思想是：

开发人员频繁把代码合并到公共代码仓库，每次代码发生变化以后，自动完成编译、测试、检查、构建等工作。

例如：

程序员
    ↓
git push
    ↓
GitLab / GitHub
    ↓
触发 CI Pipeline
    ↓
下载代码
    ↓
编译
    ↓
单元测试
    ↓
代码检查
    ↓
构建

如果全部成功：

CI 通过 ✅

如果测试失败：

CI 失败 ❌

开发人员马上知道：

这次提交有问题

五、为什么叫“持续集成”？

假设一个团队有：

10 个开发人员

如果大家开发两个月以后才合并代码：

A 修改 UserService

B 修改 UserService

C 修改 UserService

D 也修改 UserService

最后一起合并：

冲突爆炸

而持续集成的思想是：

少量修改
    ↓
频繁提交
    ↓
频繁合并
    ↓
频繁测试

尽可能早点发现问题。

所以：

CI

本质上是在降低：

代码集成风险

六、一个最简单的 CI 流程

假设你开发 Spring Boot 项目。

你执行：

git push

代码提交到 Git 仓库以后：

Git Repository
      ↓
触发 Pipeline
      ↓
拉取代码
      ↓
mvn clean test
      ↓
mvn clean package
      ↓
生成 jar

如果测试失败：

Pipeline failed

如果全部正常：

Pipeline success

这就是最基础的 CI。

七、CI 不只是“自动打包”

很多初学者会认为：

CI = 自动执行 mvn package

其实 CI 可以做很多事情。

例如：

代码格式检查

静态代码扫描

依赖漏洞扫描

单元测试

集成测试

编译

打包

生成测试报告

构建 Docker 镜像

所以 CI 可以理解为：

代码进入仓库以后
自动判断：
“这个版本能不能交付？”

八、什么是 CD？

CD 是 CI 后面的阶段。

CI 解决：

代码能不能构建成功

CD 解决：

构建好的东西怎么发布

例如：

CI
    ↓
生成 app.jar
    ↓
CD
    ↓
部署到服务器

或者：

CI
    ↓
生成 Docker Image
    ↓
CD
    ↓
部署 Kubernetes

所以整个流程：

代码
 ↓
CI
 ↓
可交付产物
 ↓
CD
 ↓
运行环境

九、Continuous Delivery 和 Continuous Deployment 有什么区别？

这两个非常容易混淆。

Continuous Delivery

持续交付。

意思是：

代码已经自动：

测试完成
构建完成
打包完成
准备好部署

但是：

是否部署生产环境

可能需要人工确认。

例如：

代码提交
    ↓
自动测试
    ↓
自动构建
    ↓
自动部署测试环境
    ↓
人工点击：
Deploy Production
    ↓
生产环境

重点：

生产发布前有人确认

Continuous Deployment

持续部署更加自动化。

例如：

代码提交
    ↓
测试成功
    ↓
构建成功
    ↓
所有检查通过
    ↓
自动部署生产环境

没有人工点击：

Deploy

因此可以简单记：

Continuous Delivery
=
准备好了
但是上线可能需要人工确认


Continuous Deployment
=
准备好了
直接自动上线

十、CI/CD 完整流程长什么样？

一个比较完整的现代项目流程可能是：

开发人员
    ↓
Git Push
    ↓
GitLab / GitHub
    ↓
Pipeline
    ↓
Checkout Code
    ↓
Install Dependencies
    ↓
Compile
    ↓
Unit Test
    ↓
Code Quality Check
    ↓
Package
    ↓
Build Docker Image
    ↓
Push Image Registry
    ↓
Deploy Test
    ↓
Integration Test
    ↓
Deploy Production

这就是：

CI/CD Pipeline

十一、什么是 Pipeline？

Pipeline：

流水线

可以理解成：

把软件发布过程中一连串步骤定义成一个自动执行流程。

比如：

Stage 1
Checkout


Stage 2
Build


Stage 3
Test


Stage 4
Package


Stage 5
Docker Build


Stage 6
Deploy

整体：

Checkout
    ↓
Build
    ↓
Test
    ↓
Package
    ↓
Docker
    ↓
Deploy

这就是 Pipeline。

十二、Stage 是什么？

一个 Pipeline 通常会拆成多个 Stage。

例如：

Pipeline

├── Build
├── Test
├── Package
├── Docker
└── Deploy

其中：

Build
Test
Package
Deploy

都可以称为：

Stage

也就是：

流水线阶段

十三、Job 是什么？

Stage 里面通常还有：

Job

例如：

Test Stage

├── Unit Test
├── Integration Test
└── Security Test

这三个都可以是 Job。

所以可以理解：

Pipeline
    ↓
Stage
    ↓
Job
    ↓
具体命令

例如：

Pipeline

Build Stage
    └── Maven Build Job

Test Stage
    ├── Unit Test Job
    └── Integration Test Job

Deploy Stage
    └── Production Deploy Job

十四、CI/CD 平台是干什么的？

常见 CI/CD 平台包括：

Jenkins

GitLab CI/CD

GitHub Actions

Azure DevOps

CircleCI

Tekton

这些工具的核心作用都差不多：

监听代码变化
    ↓
执行你定义的 Pipeline

例如：

git push

以后自动执行：

mvn test
mvn package
docker build
docker push
kubectl apply

十五、Jenkins 是什么？

Jenkins 是非常经典的 CI/CD 自动化工具。

可以把它理解成：

一台专门执行自动化任务的服务器

例如 Jenkins 收到：

GitHub / GitLab Webhook

知道：

代码更新了

然后：

Jenkins
   ↓
拉取代码
   ↓
Maven 编译
   ↓
运行测试
   ↓
Docker Build
   ↓
部署服务器

十六、为什么公司里经常看到 Jenkins？

因为 Jenkins：

成熟

插件多

灵活

支持各种技术栈

支持私有部署

历史悠久

所以很多企业项目尤其是：

Java 项目
传统企业
大型内部系统

依然大量使用 Jenkins。

十七、Jenkinsfile 是什么？

Jenkins 的流水线可以通过：

Jenkinsfile

写成代码。

例如：

pipeline {

    agent any

    stages {

        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }

        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }

        stage('Deploy') {
            steps {
                sh './deploy.sh'
            }
        }

    }

}

不用一开始死记语法。

你只要先看结构：

pipeline

    stages

        Checkout

        Build

        Test

        Deploy

这就够了。

十八、GitLab CI 又是什么？

GitLab 本身提供代码仓库。

例如：

GitLab Repository

同时它还提供：

GitLab CI/CD

所以：

代码仓库
+
CI/CD

可以在同一个平台完成。

GitLab CI 常见配置文件：

.gitlab-ci.yml

例如：

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - mvn clean package

test:
  stage: test
  script:
    - mvn test

deploy:
  stage: deploy
  script:
    - ./deploy.sh

可以看出核心思想完全一样：

Build
 ↓
Test
 ↓
Deploy

十九、GitHub Actions 又是什么？

GitHub Actions 是 GitHub 提供的自动化工作流平台。

例如：

Push Code
    ↓
GitHub Actions
    ↓
Build
    ↓
Test
    ↓
Docker Build
    ↓
Deploy

配置通常放在：

.github/workflows/

目录下面。

例如逻辑上：

name: CI

on:
  push:

jobs:

  build:

    steps:

      - checkout

      - setup java

      - run: mvn test

      - run: mvn package

虽然语法不同，但 CI/CD 思想还是：

监听事件
    ↓
执行任务

二十、CI/CD 为什么经常和 Docker 一起出现？

假设传统发布方式是：

mvn package
    ↓
app.jar
    ↓
上传服务器
    ↓
java -jar app.jar

会面临环境问题：

Java 版本

系统依赖

配置差异

Linux 环境

依赖库

Docker 出现以后，可以把：

程序
+
运行环境
+
依赖

一起打包。

例如：

FROM eclipse-temurin:17-jre

COPY target/app.jar /app/app.jar

ENTRYPOINT ["java", "-jar", "/app/app.jar"]

然后：

docker build -t my-app:1.0 .

得到：

Docker Image

这样 CI 不再只是生成：

app.jar

而可以生成：

my-app:1.0

二十一、什么是镜像仓库？

构建 Docker Image 以后，总得有地方保存。

于是出现：

Docker Registry

比如：

Docker Hub

Harbor

云厂商 Container Registry

流程：

代码
 ↓
CI
 ↓
Docker Build
 ↓
my-app:1.0
 ↓
Docker Registry

部署服务器再：

Docker Registry
    ↓
docker pull
    ↓
启动容器

二十二、一个 Docker CI/CD 流程

比如用户提交代码：

git push

然后：

Git Repository
    ↓
CI Server
    ↓
mvn clean package
    ↓
Docker Build
    ↓
my-app:20260831
    ↓
Push Registry
    ↓
Server Pull Image
    ↓
docker run

这样：

从源码

到：

运行中的服务

基本实现自动化。

二十三、为什么镜像一定要有版本？

千万不要所有部署都只使用：

latest

更好的方式通常是：

my-app:1.0.0

my-app:1.0.1

my-app:1.0.2

或者使用：

Git Commit SHA

例如：

my-app:a83fd92

这样可以明确知道：

当前服务器跑的是哪个版本

而且回滚也方便。

二十四、什么叫 Artifact？

Artifact 可以理解成：

构建产物

例如 Java：

app.jar

前端：

dist/

Docker：

Docker Image

所以：

Source Code
    ↓
Build
    ↓
Artifact

然后：

Artifact
    ↓
Deploy

二十五、CI 和 CD 的分界线在哪里？

可以非常粗略地理解：

代码
 ↓

CI
 ↓
Build
 ↓
Test
 ↓
Package

----------------

CD
 ↓
Deploy Test
 ↓
Deploy Staging
 ↓
Deploy Production

也就是说：

CI 主要解决：

代码质量
构建
测试
产物


CD 主要解决：

部署
发布
环境

二十六、什么是环境？

真实项目通常不会只有：

生产环境

可能有：

DEV

TEST

UAT

STAGING

PRODUCTION

例如：

DEV
开发环境


TEST
测试环境


STAGING
预发布环境


PRODUCTION
生产环境

代码可能按照：

开发
 ↓
测试
 ↓
预发布
 ↓
生产

逐级发布。

二十七、为什么不能代码一提交就直接生产？

理论上可以。

但很多企业不会这么做。

因为生产环境非常重要。

一般会经过：

Unit Test
    ↓
Integration Test
    ↓
Test Environment
    ↓
QA Verification
    ↓
Staging
    ↓
Production

甚至生产部署前需要：

人工审批

这样风险更低。

二十八、什么是自动触发？

CI/CD 流水线通常通过事件自动触发。

例如：

Push

Pull Request

Merge Request

Tag

Scheduled Task

Manual Trigger

例如：

push develop

触发：

测试环境部署

而：

push tag v1.0.0

触发：

生产发布

这就是非常常见的策略。

二十九、什么是 Webhook？

Webhook 可以简单理解成：

事件通知

例如：

GitLab

发现：

有人 push 代码

然后请求 Jenkins：

“兄弟，代码更新了。”

Jenkins 收到以后：

启动 Pipeline

所以：

Git Push
    ↓
GitLab
    ↓
Webhook
    ↓
Jenkins
    ↓
Pipeline

三十、CI/CD 中为什么必须有自动测试？

如果流水线只是：

自动构建
+
自动部署

但是完全不测试，那就会出现：

Bug
    ↓
自动构建
    ↓
自动部署
    ↓
自动把 Bug 发布到生产

这显然不是我们想要的。

所以：

自动部署

必须建立在：

自动质量检查

基础上。

三十一、Pipeline 失败应该怎么办？

假设：

Build ✅

Unit Test ❌

Docker Build

Deploy

正确的流水线应该：

Unit Test 失败
        ↓
Pipeline 直接停止

不能继续部署。

所以：

前面的 Stage 成功
    ↓
后面的 Stage 才继续

这是 Pipeline 很重要的机制。

三十二、什么是 Quality Gate？

有些项目会加入：

Code Quality Gate

例如：

测试覆盖率必须 > 某个标准

严重漏洞不能超过一定数量

代码扫描必须通过

如果没有达到标准：

Pipeline Failed

不允许继续上线。

三十三、SonarQube 是干什么的？

在 Java CI/CD 里面，经常看到：

SonarQube

它主要用于：

代码质量分析

Bug 风险

代码异味

重复代码

测试覆盖率

安全问题

流水线可能：

Git Push
 ↓
Build
 ↓
Unit Test
 ↓
SonarQube Scan
 ↓
Quality Gate
 ↓
Package
 ↓
Deploy

如果代码质量不合格：

禁止部署

三十四、什么是 Secret？

CI/CD 里面经常需要：

数据库密码

Docker Registry 密码

SSH Key

Kubernetes Token

API Key

这些东西绝对不能：

直接写进 Git 仓库

例如不要：

password: 123456

而应该放：

CI/CD Secret

例如：

DB_PASSWORD

REGISTRY_PASSWORD

SSH_PRIVATE_KEY

流水线运行时再注入。

三十五、为什么不能把密码写进代码？

因为一旦：

git commit

即使以后删除：

密码可能仍然存在 Git 历史记录中

所以安全原则：

代码
≠
Secret

Secret 应通过：

CI Secret

Environment Variable

Secret Manager

管理。

三十六、CI/CD 和 Kubernetes 是什么关系？

如果项目使用 Kubernetes：

Docker Container

通常不再直接：

docker run

而是：

Kubernetes

负责运行。

所以：

Git Push
    ↓
CI
    ↓
Build
    ↓
Test
    ↓
Docker Build
    ↓
Push Registry
    ↓
CD
    ↓
Update Kubernetes
    ↓
Kubernetes Pull Image
    ↓
Create Pod

这就是现代云原生项目非常常见的 CI/CD。

三十七、Kubernetes 部署到底发生了什么？

比如当前运行：

my-app:1.0

新版本构建：

my-app:1.1

CD 更新 Deployment：

image:
my-app:1.1

Kubernetes 会：

创建新 Pod
    ↓
新 Pod 健康检查
    ↓
开始接收流量
    ↓
停止旧 Pod

这就是典型：

Rolling Update

三十八、什么是滚动发布？

假设现在运行 4 台：

App v1
App v1
App v1
App v1

发布 v2 时，不一次全部关掉。

而是：

App v2
App v1
App v1
App v1

然后：

App v2
App v2
App v1
App v1

继续：

App v2
App v2
App v2
App v1

最终：

App v2
App v2
App v2
App v2

这就是：

Rolling Deployment

优点：

减少服务中断

三十九、什么是蓝绿发布？

Blue-Green Deployment：

Blue
=
当前生产版本


Green
=
新版本

例如：

用户
 ↓
Load Balancer
 ↓
Blue v1

与此同时准备：

Green v2

测试完成后：

Load Balancer

把流量从：

Blue

切到：

Green

如果发现严重问题：

切回 Blue

回滚非常快。

四十、什么是灰度发布？

灰度发布不是：

100% 用户

立刻使用新版本。

而是：

5%
 ↓
10%
 ↓
30%
 ↓
50%
 ↓
100%

逐渐放量。

例如：

95% 流量 → v1

5% 流量 → v2

观察：

错误率

响应时间

业务指标

服务器负载

如果正常：

继续扩大 v2 流量

四十一、为什么需要回滚？

任何发布都有可能失败。

例如：

新版本数据库查询异常

CPU 暴涨

接口大量 500

内存泄漏

业务逻辑错误

所以 CI/CD 体系不能只有：

发布

还必须考虑：

Rollback

也就是：

回滚

四十二、Docker 为什么特别适合回滚？

例如之前运行：

my-app:1.0

新版本：

my-app:1.1

发布失败。

那么理论上可以：

my-app:1.1
    ↓
切换
    ↓
my-app:1.0

因为旧镜像还保存在 Registry。

所以版本化 Artifact 非常重要。

四十三、数据库发布为什么比代码发布更危险？

代码可以：

v2
 ↓
v1

但是数据库执行：

DROP COLUMN

以后：

数据结构已经变了

并不一定能简单回滚。

所以数据库变更通常需要更加谨慎。

常见做法包括：

数据库 migration

Flyway

Liquibase

而且应该尽量使用：

向后兼容

的 Schema 变更策略。

四十四、一个真实 Spring Boot CI/CD 项目

假设：

Spring Boot
GitLab
Jenkins
Docker
Harbor
Kubernetes

项目流程：

Developer

    ↓

git push

    ↓

GitLab

    ↓ Webhook

Jenkins

    ↓

Checkout

    ↓

Maven Build

    ↓

Unit Test

    ↓

SonarQube

    ↓

mvn package

    ↓

Docker Build

    ↓

Harbor

    ↓

Kubernetes Deploy

    ↓

Health Check

    ↓

Production

这就是一个非常典型的企业 CI/CD 架构。

四十五、代码提交之后详细发生了什么？

开发人员执行：

git add .

git commit -m "feat: add order api"

git push

第一步：

代码进入 GitLab

GitLab：

保存新的 Commit

然后 Webhook：

通知 Jenkins

Jenkins：

创建一次新的 Pipeline

Jenkins 拉取：

Commit abc123

执行：

mvn clean test

如果失败：

Pipeline Failed

如果成功：

mvn clean package

生成：

order-service.jar

然后：

docker build

生成：

order-service:abc123

Push：

Harbor

最终：

Kubernetes

更新 Deployment：

order-service:old

变为：

order-service:abc123

新 Pod 启动。

健康检查：

成功

流量进入新 Pod。

旧 Pod 逐渐关闭。

最终完成发布。

四十六、为什么 Commit ID 经常作为镜像版本？

因为：

Commit

和：

Image

可以形成一一对应关系。

例如：

Commit:

a7df932

构建：

order-service:a7df932

发生线上 Bug 时：

当前运行镜像：

order-service:a7df932

马上就知道：

对应哪次 Git 提交

非常方便排查。

四十七、CI/CD 最重要的价值是什么？

很多人会回答：

自动部署

但这只是其中一部分。

CI/CD 更大的价值包括：

减少人工操作

提高发布速度

减少人为错误

提高代码质量

尽早发现 Bug

统一构建环境

保证发布流程一致

方便回滚

提高交付频率

本质上：

把“靠人记住流程”变成“由系统强制执行流程”。

四十八、CI/CD 和 DevOps 是什么关系？

CI/CD 经常和：

DevOps

一起出现。

但是：

CI/CD
≠
DevOps

CI/CD 更像是：

工程实践和自动化流程

DevOps 是更大的概念，包括：

开发

测试

运维

监控

发布

协作

自动化

反馈

CI/CD 是 DevOps 非常重要的一部分。

四十九、一个完整 DevOps 链路

现代软件交付可以理解为：

Plan
 ↓
Code
 ↓
Build
 ↓
Test
 ↓
Release
 ↓
Deploy
 ↓
Operate
 ↓
Monitor
 ↓
Feedback
 ↓
Plan

这是一个循环。

所以软件开发并不是：

代码写完
=
结束

实际上：

上线以后

还要：

监控

日志

报警

性能分析

用户反馈

然后重新进入开发。

五十、常见 CI/CD 面试问题

如果面试官问：

什么是 CI/CD？

可以回答：

CI/CD 是一种软件自动化交付实践。

CI 即持续集成，开发人员频繁提交和合并代码，每次代码变化后自动执行编译、测试、代码检查和构建，从而尽早发现问题。

CD 负责将 CI 生成的可交付产物部署到测试、预发布或者生产环境。根据自动化程度不同，又可以分为持续交付和持续部署。

如果问：

你们项目 CI/CD 怎么做？

可以回答：

代码托管在 GitLab。

开发人员 Push 或 Merge 后通过 Webhook 触发 Jenkins Pipeline。

Jenkins 拉取代码以后执行 Maven 编译、单元测试和代码质量检查。

通过以后构建 Spring Boot Jar，再构建 Docker Image。

镜像使用 Git Commit ID 作为版本并推送到 Harbor。

部署阶段更新 Kubernetes Deployment，由 Kubernetes 进行滚动升级。

最后通过健康检查确认服务是否部署成功。

这个回答已经比较贴近真实项目。

五十一、CI/CD 中最容易犯的错误

1. 所有东西都写在一个脚本里

例如：

build.sh

里面几百行：

拉代码
编译
测试
Docker
SSH
部署
检查

最后完全无法维护。

应该合理拆分：

Build

Test

Package

Deploy

2. 密码写进代码

这是严重安全问题。

应该使用：

Secret

管理。

3. 所有镜像都叫 latest

会导致：

不知道当前到底是什么版本

应该使用：

Semantic Version

Git Tag

Commit SHA

4. 没有测试直接自动部署

这等于：

自动把 Bug 发到生产

5. 没有回滚机制

发布成功不是唯一目标。

还必须：

失败后能快速恢复

6. CI 环境和生产环境差异巨大

例如：

CI 使用 JDK 17

Production 使用 JDK 11

可能导致：

CI 成功
生产失败

Docker 可以在一定程度上缓解环境一致性问题。

五十二、CI/CD 项目里最值得掌握的工具

如果是 Java 后端开发，可以按照下面路线学习：

Git
    ↓
Linux
    ↓
Maven
    ↓
Jenkins
    ↓
Docker
    ↓
Docker Registry
    ↓
Nginx
    ↓
Kubernetes

同时了解：

GitLab CI

GitHub Actions

SonarQube

Harbor

不需要一开始全部精通。

先理解：

这些工具在整条链路中负责什么

比背命令更加重要。

五十三、最适合新手的 CI/CD 学习项目

可以自己做一个：

Spring Boot Demo

第一阶段：

GitHub / GitLab
    ↓
Push

第二阶段：

Jenkins
    ↓
自动 mvn package

第三阶段：

Jenkins
    ↓
mvn test

第四阶段：

Docker Build

第五阶段：

Docker Push

第六阶段：

自动部署 Linux

最终：

git push

以后什么都不用做。

服务器自动运行最新版。

当你亲手把这个流程跑通一次以后，CI/CD 的理解会非常深。

五十四、最后建立完整知识图

把整个 CI/CD 世界压缩以后，其实就是下面这张图：

                    Developer
                        │
                        │ git push
                        ▼
                 Git Repository
                        │
                        ▼
                  CI/CD Trigger
                        │
                        ▼
                 ┌──────────────┐
                 │   Pipeline   │
                 └──────┬───────┘
                        │
                        ▼
                     Checkout
                        │
                        ▼
                      Build
                        │
                        ▼
                       Test
                        │
                        ▼
                   Code Scan
                        │
                        ▼
                     Package
                        │
                        ▼
                Build Docker Image
                        │
                        ▼
                  Image Registry
                        │
                        ▼
                      Deploy
                        │
              ┌─────────┴─────────┐
              ▼                   ▼
          Test Env          Production Env
                                  │
                                  ▼
                              Monitoring

所以 CI/CD 并不神秘。

它本质上就是：

代码
 ↓
自动检查
 ↓
自动构建
 ↓
自动测试
 ↓
生成产物
 ↓
自动部署

总结

CI/CD 最核心的几个概念可以记成：

CI
=
持续集成
=
代码频繁提交以后自动构建、测试、检查


CD
=
持续交付 / 持续部署
=
把构建好的产物交付到运行环境


Pipeline
=
整个自动化流水线


Stage
=
流水线中的阶段


Job
=
阶段中的具体任务


Artifact
=
构建产生的可交付产物


Docker
=
统一应用运行环境


Registry
=
保存 Docker Image


Kubernetes
=
运行、管理和更新容器


Jenkins / GitLab CI / GitHub Actions
=
执行 CI/CD Pipeline 的工具

最后一定要记住一句话：

CI/CD 的本质不是“会用 Jenkins”，而是把软件从代码提交到生产运行的整个交付流程标准化、自动化、可重复化。

所以真正理解 CI/CD，应该形成这样的思维：

开发人员提交代码
        ↓
谁检测到代码变化？
        ↓
谁执行 Pipeline？
        ↓
代码怎么构建？
        ↓
测试怎么执行？
        ↓
失败以后怎么办？
        ↓
构建产物是什么？
        ↓
Docker 镜像怎么生成？
        ↓
镜像保存在哪里？
        ↓
谁负责部署？
        ↓
怎么保证不中断服务？
        ↓
发布失败怎么回滚？
        ↓
上线以后怎么监控？

当这条链路全部理解以后，你就不再只是知道：

Jenkins
Docker
Kubernetes

这些名字，而是开始真正理解：

现代项目是怎么从代码变成线上服务的。