1.3 交付流水线：从代码提交到镜像晋升的全链路拆解
1. 引言：什么是“流水线”？
设想你经营着一家现代化的汽车工厂。
- 原材料（代码）进入工厂。
- 机器手臂自动焊接（编译/构建）。
- 质检员进行碰撞测试（单元测试/代码扫描）。
- 喷漆并组装成成品车（打包 Docker 镜像）。
- 最后运输到 4S 店（部署到 K8s 集群）。
这就是CI/CD 流水线（Pipeline）。
但在现实中，很多公司的“流水线”是这样的：
- 开发在本地 build 一个 jar 包，用 QQ 传给运维。
- 运维手动 scp 到服务器，解压，重启。
- 出了问题，大家一起翻日志。
这种手工作坊式的流程，是云原生时代最大的瓶颈。本节我们将像拆解汽车引擎一样，拆解一条标准的云原生交付流水线，让你看清每一个齿轮是如何咬合的。
2. 理论深度解析：流水线的解剖学
一条成熟的 DevOps 流水线通常包含两个核心阶段：持续集成（CI）和持续交付（CD）。
2.1 CI 阶段（Continuous Integration）—— 它是“过滤器”
CI 的核心目的不是为了部署，而是为了快速发现错误。它是一系列自动化的质量门禁。
- 输入：源代码（Git Push）
- 输出：经过验证的、可部署的制品（Docker Image）
关键环节：
- Lint & Scan：代码风格检查（ESLint）、静态安全扫描（SonarQube）。
- Unit Test：运行单元测试，计算覆盖率。
- Build：编译代码，构建二进制文件。
- Docker Build：封装成 Docker 镜像。
- Push Registry：推送到镜像仓库（Harbor/ACR）。
2.2 CD 阶段（Continuous Delivery）—— 它是“运输队”
CD 的核心目的是将制品安全、可控地投放到目标环境。
- 输入：Docker 镜像
- 输出：运行中的应用
关键环节：
- Update Manifest：修改 K8s YAML 文件中的镜像 Tag。
- Deploy：应用变更到 K8s 集群（kubectl apply / Helm upgrade）。
- Health Check：检测 Pod 是否启动成功。
- Notify：钉钉/Slack 通知发布结果。
3. 全链路拆解：从 Git Commit 到 Pod Running
为了让你有体感，我们用一个真实的Spring Boot 微服务为例，模拟一次完整的上线过程。
3.1 阶段一：开发提交 (The Trigger)
开发者小王修复了一个 Bug，并在本地提交代码：
gitcommit -m"fix: 修复订单超时问题"gitpush origin main这一动作通过Webhook触发了 CI 服务器（Jenkins/GitLab Runner/GitHub Actions）。
3.2 阶段二：代码质量检查 (The Gatekeeper)
流水线启动。第一步不是编译，而是检查代码是否规范。
如果小王写的代码里有硬编码的密码（Hardcoded Password），或者单元测试没通过，流水线直接标红失败，并发送邮件羞辱（提醒）小王。
最佳实践：Fail Fast（快速失败）。越早发现问题，修复成本越低。不要等到部署到生产环境了才发现配置写错了。
3.3 阶段三：构建与封装 (The Factory)
代码检查通过。流水线开始干重活：
- Maven Build：
mvn clean package，生成order-service.jar。 - Docker Build：读取项目根目录下的
Dockerfile。
# Dockerfile 示例 FROM openjdk:17-alpine COPY target/order-service.jar /app.jar ENTRYPOINT ["java", "-jar", "/app.jar"]- 打标签（Tagging）：
这是一个关键点！千万不要用latest标签！
必须使用唯一标识，通常是Commit SHA或Build ID。
例如：harbor.example.com/prod/order-service:v1.0.5-a1b2c3d
3.4 阶段四：制品晋升 (The Promotion)
现在我们有了一个镜像。
- 这个镜像首先被部署到Dev 环境。
- 测试团队进行集成测试。
- 测试通过后，这个同一个镜像（Tag 不变）被“晋升”到Staging 环境。
- 预发布验证通过后，再次“晋升”到Prod 环境。
Mermaid 流程图：镜像晋升流
