3、CI/CD基础：持续集成概念、持续交付与持续部署的区别、CI/CD流水线核心阶段、常见CI/CD工具对比
3.1 持续集成（CI）核心概念
持续集成（Continuous Integration，CI）是一种软件开发实践，要求开发人员频繁地将代码变更合并到共享主干仓库中（通常每天多次）。每次合并都会触发自动化构建与测试流程，从而尽早发现集成错误。
CI 核心目标： 消除“集成地狱”，确保主干始终处于可发布状态。
CI 的关键实践包括：
- 频繁提交： 小批量、高频次地将代码推送到共享仓库。
- 自动化构建： 每次提交后自动编译代码、打包制品。
- 自动化测试： 执行单元测试、静态代码分析、代码风格检查。
- 快速反馈： 在几分钟内告知开发者构建是否通过、测试是否失败。
- 主干开发： 所有开发者基于主干分支工作，避免长期存在的特性分支。
3.2 持续交付 vs 持续部署
持续交付（Continuous Delivery，CD）和持续部署（Continuous Deployment，CD）经常被混淆，但两者在自动化程度上存在本质区别。
| 维度 | 持续集成（CI） | 持续交付（CD） | 持续部署（CD） |
|---|---|---|---|
| 核心动作 | 代码合并 + 构建 + 测试 | 构建 + 测试 + 准备发布 | 构建 + 测试 + 自动发布 |
| 部署到生产 | 否 | 手动触发（一键部署） | 自动触发（无需人工） |
| 人工介入点 | 无（全自动） | 发布审批环节 | 无（全自动） |
| 交付频率 | 每天多次 | 随时可发布（按需） | 每次提交自动发布 |
| 风险控制 | 低（仅验证代码质量） | 中（人工把关） | 高（需强测试与监控） |
| 适用场景 | 所有项目 | 企业级、合规要求高的项目 | SaaS、快速迭代产品 |
记忆口诀： CI 保证代码能合；持续交付保证代码能发（但等人按按钮）；持续部署保证代码自动发（没人按按钮）。
3.3 CI/CD 流水线核心阶段
一条完整的 CI/CD 流水线通常包含以下 6 个核心阶段，每个阶段都有明确的输入、输出和质量门禁。
- 代码检出（Checkout）： 从版本控制系统（如 Git）拉取最新代码，通常基于特定分支或标签。
- 静态分析（Static Analysis）： 执行代码风格检查（Lint）、安全漏洞扫描（SAST）、依赖项审查，确保代码质量与安全基线。
- 构建与编译（Build & Compile）： 将源代码编译为可执行制品（如 JAR、Docker 镜像、静态文件），并生成唯一版本号。
- 自动化测试（Automated Testing）： 依次执行单元测试、集成测试、端到端测试，验证功能正确性与性能指标。
- 制品发布（Artifact Release）： 将验证通过的制品推送至制品仓库（如 Docker Registry、Nexus、S3），并打上版本标签。
- 部署与验证（Deploy & Verify）： 将制品部署到目标环境（开发/预发/生产），执行冒烟测试与健康检查，确认部署成功。
3.4 常见 CI/CD 工具对比
市场上 CI/CD 工具众多，选择时需考虑团队规模、技术栈、托管方式（自建 vs SaaS）以及 GitOps 集成能力。以下为 6 款主流工具的对比：
| 工具 | 类型 | 配置方式 | GitOps 支持 | 容器原生 | 学习曲线 | 典型场景 |
|---|---|---|---|---|---|---|
| Jenkins | 自建 | Web UI / Jenkinsfile | 插件扩展 | 一般 | 中 | 传统企业、复杂流水线 |
| GitLab CI | SaaS / 自建 | .gitlab-ci.yml | 原生集成 | 强 | 低 | 一体化 DevOps 平台 |
| GitHub Actions | SaaS | .github/workflows/*.yml | 原生集成 | 强 | 低 | 开源项目、GitHub 生态 |
| Argo Workflows | Kubernetes 原生 | YAML / CRD | 原生集成 | 极强 | 高 | K8s 原生 CI、ML 流水线 |
| Tekton | Kubernetes 原生 | YAML / CRD | 原生集成 | 极强 | 高 | 云原生、可移植流水线 |
| CircleCI | SaaS | .circleci/config.yml | 一般 | 强 | 低 | 快速迭代、中小团队 |
选型建议： 如果团队已深度使用 Kubernetes 并计划实施 GitOps，优先考虑 Argo Workflows 或 Tekton；如果希望开箱即用且与代码仓库深度绑定，GitLab CI 和 GitHub Actions 是最佳选择；Jenkins 适合已有大量插件投资和定制需求的传统团队。
3.5 CI/CD 与 GitOps 的衔接点
在 GitOps 实践中，CI/CD 流水线并非终点，而是 GitOps 工作流的“上游”环节。CI 负责构建和测试，CD 负责将制品信息（如镜像标签）写入 Git 仓库，而 GitOps 控制器负责从 Git 仓库同步到实际环境。
典型的衔接流程如下：
- CI 阶段： 代码提交 → 构建 Docker 镜像 → 运行测试 → 推送镜像到 Registry。
- CD 阶段（GitOps 风格）： 自动更新 Git 仓库中的部署清单（如 K8s Deployment YAML）中的镜像标签。
- GitOps 同步： Argo CD / Flux 检测到 Git 仓库变更，自动将新版本部署到目标集群。
关键原则： CI/CD 流水线只负责“构建与声明”，GitOps 控制器负责“同步与执行”。两者通过 Git 仓库作为唯一真相源（Single Source of Truth）进行解耦。