4. 发布流水线基础：CI/CD概念、Jenkins/GitLab CI/CD简介、流水线阶段划分
4.1 CI/CD 核心概念
CI/CD（持续集成/持续交付）是现代软件工程与云原生交付的基石。在 Kubernetes 金丝雀发布场景中，CI/CD 流水线负责将代码变更自动转化为可部署的容器镜像，并驱动发布策略的执行。
| 术语 | 定义 | 在金丝雀发布中的角色 |
|---|---|---|
| 持续集成 (CI) | 开发人员频繁地将代码合并到主干分支，每次合并触发自动构建与单元测试。 | 确保金丝雀版本的代码质量，生成带有唯一标签的容器镜像。 |
| 持续交付 (CD) | CI 通过后，自动将制品部署到类生产环境，随时可发布到生产。 | 将金丝雀镜像自动部署到 Kubernetes 集群，并执行健康检查。 |
| 持续部署 | CD 的延伸，每次通过测试的变更自动部署到生产环境，无需人工审批。 | 在金丝雀分析通过后，自动完成全量发布或回滚。 |
关键区分： 金丝雀发布策略通常位于 CD 阶段。CI 阶段负责产出“金丝雀版本”的镜像，CD 阶段负责执行“流量切换”与“指标分析”。
4.2 主流 CI/CD 工具简介
4.2.1 Jenkins
Jenkins 是历史最悠久的开源自动化服务器，通过 Pipeline as Code（Jenkinsfile）定义构建、测试、部署流程。其生态丰富，支持 Kubernetes 插件实现动态 Agent。
- 优势： 插件数量超过 1800 个，可深度定制；支持声明式与脚本式 Pipeline；与 Kubernetes 集成成熟。
- 劣势： 配置维护成本高；UI 相对陈旧；大规模集群下 Master 节点存在单点风险。
- 适用场景： 企业级复杂流水线、需要大量自定义逻辑、遗留系统迁移。
4.2.2 GitLab CI/CD
GitLab CI/CD 深度集成在 GitLab 平台中，使用 .gitlab-ci.yml 定义流水线。天然支持代码仓库、镜像仓库、Kubernetes 集群的一体化管理。
- 优势： 一体化平台，无需额外搭建；原生支持容器镜像构建与推送；内置环境看板与部署审批。
- 劣势： 自托管实例对资源要求较高；高级功能需付费订阅。
- 适用场景： 使用 GitLab 作为代码托管平台、追求开箱即用、中小型团队。
| 对比维度 | Jenkins | GitLab CI/CD |
|---|---|---|
| 配置方式 | Jenkinsfile（Groovy） | .gitlab-ci.yml（YAML） |
| Agent 管理 | 独立 Master/Agent 架构 | Runner 架构（共享/特定） |
| K8s 集成 | Kubernetes Plugin | 内置 Kubernetes 集成 |
| 镜像仓库 | 需额外配置 | 内置 Container Registry |
| 金丝雀支持 | 需编写 Pipeline 逻辑 | 环境看板 + 手动审批 |
4.3 流水线阶段划分
一个面向 Kubernetes 金丝雀发布的流水线，通常划分为以下 6 个标准阶段。每个阶段都有明确的输入、输出与质量门禁。
- 代码检出与静态分析： 从 Git 仓库拉取指定分支代码；执行代码规范检查、安全扫描（SAST）。
- 单元测试与编译： 运行单元测试；编译项目生成二进制或中间产物。
- 容器镜像构建与推送： 使用 Dockerfile 构建镜像；打上版本标签（如
v1.2.3-canary）；推送到镜像仓库。 - 部署到测试/预发环境： 将镜像部署到非生产 Kubernetes 集群；执行集成测试与冒烟测试。
- 金丝雀发布（核心阶段）： 将新版本部署到生产集群的一个子集（如 5% 流量）；运行指标分析与健康检查。
- 全量发布或回滚： 根据金丝雀分析结果，自动执行全量发布或回滚到稳定版本。
阶段划分原则： 每个阶段应尽可能“快速失败”。如果单元测试失败，流水线应立即终止，避免浪费后续阶段的资源。金丝雀阶段应设置超时与自动回滚策略。
4.4 流水线与金丝雀策略的集成点
在流水线中集成金丝雀发布，需要在以下三个关键点进行设计：
- 镜像标签策略： 使用语义化版本号 + 环境标识（如
v1.2.3-canary、v1.2.3-stable），便于流水线区分金丝雀版本与稳定版本。 - 部署清单模板化： 使用 Helm Chart 或 Kustomize 管理 Kubernetes 资源，流水线通过参数注入金丝雀副本数、流量比例等配置。
- 分析决策自动化： 在金丝雀阶段集成 Prometheus 或 Datadog 等监控系统，通过 API 获取错误率、P99 延迟等指标，由流水线自动判断是否继续发布。
常见陷阱： 不要将金丝雀发布逻辑硬编码在应用代码中。应该通过 Service Mesh（如 Istio）或 Ingress Controller（如 Nginx Ingress）的流量管理能力，在基础设施层实现流量切换，保持应用无感知。
4.5 阶段质量门禁示例
| 阶段 | 质量门禁 | 失败处理 |
|---|---|---|
| 代码检出 | 分支策略校验（禁止直接推送到 main） | 流水线拒绝执行 |
| 单元测试 | 测试覆盖率 ≥ 80%，全部用例通过 | 流水线终止，通知开发者 |
| 镜像构建 | 镜像安全扫描无高危漏洞 | 镜像不推送，流水线终止 |
| 预发部署 | 冒烟测试通过，健康检查返回 200 | 回滚预发环境，流水线终止 |
| 金丝雀发布 | 错误率 < 0.1%，P99 延迟 < 200ms | 自动回滚金丝雀，通知 SRE |
通过以上阶段划分与质量门禁，CI/CD 流水线能够为金丝雀发布提供可靠的自动化基础，确保每次发布变更都经过严格的验证与灰度验证，最终实现安全、高效的持续交付。