葫芦岛市网站建设_网站建设公司_前后端分离_seo优化

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）

关键环节：

1. Lint & Scan：代码风格检查（ESLint）、静态安全扫描（SonarQube）。
2. Unit Test：运行单元测试，计算覆盖率。
3. Build：编译代码，构建二进制文件。
4. Docker Build：封装成 Docker 镜像。
5. Push Registry：推送到镜像仓库（Harbor/ACR）。

2.2 CD 阶段（Continuous Delivery）—— 它是“运输队”

CD 的核心目的是将制品安全、可控地投放到目标环境。

• 输入：Docker 镜像
• 输出：运行中的应用

关键环节：

1. Update Manifest：修改 K8s YAML 文件中的镜像 Tag。
2. Deploy：应用变更到 K8s 集群（kubectl apply / Helm upgrade）。
3. Health Check：检测 Pod 是否启动成功。
4. 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)

代码检查通过。流水线开始干重活：

1. Maven Build：mvn clean package，生成order-service.jar。
2. Docker Build：读取项目根目录下的Dockerfile。

# Dockerfile 示例 FROM openjdk:17-alpine COPY target/order-service.jar /app.jar ENTRYPOINT ["java", "-jar", "/app.jar"]

3. 打标签（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 流程图：镜像晋升流