CI/CD 流水线基础
在构建平台工程 IDP 制品签名链路之前，必须深入理解 CI/CD 流水线的核心概念与运作机制。CI/CD 不仅是自动化工具链的简单堆叠，更是软件交付过程中质量、安全与效率的基石。本章将系统梳理 CI/CD 的核心概念、标准流水线阶段划分，并对主流 CI/CD 工具进行对比分析，为后续对接制品签名链路奠定基础。
2.1 CI/CD 核心概念
CI/CD 是持续集成（Continuous Integration）、持续交付（Continuous Delivery）与持续部署（Continuous Deployment）的统称。三者构成了从代码提交到生产环境发布的完整自动化链路。
| 概念 | 核心目标 | 关键实践 | 制品签名关联 |
|---|---|---|---|
| 持续集成（CI） | 频繁合并代码变更，自动构建并验证 | 代码提交触发构建、单元测试、静态分析 | 构建产物（如 JAR/Docker 镜像）首次签名 |
| 持续交付（CD） | 确保软件随时可发布到生产环境 | 自动化测试、环境部署、制品仓库管理 | 签名制品在制品仓库中的完整性校验 |
| 持续部署（CD） | 将通过测试的变更自动部署到生产 | 灰度发布、滚动更新、回滚策略 | 部署前签名验证，防止篡改制品上线 |
关键认知： 制品签名链路贯穿 CI/CD 全流程。CI 阶段负责对构建产物进行首次签名，CD 阶段则负责在部署前验证签名完整性。签名不是一次性动作，而是流水线中持续存在的安全约束。
2.2 流水线阶段划分
一个标准 CI/CD 流水线通常划分为以下核心阶段。每个阶段都有明确的输入、输出和质量门禁。
- 代码检出与静态分析：从版本控制系统拉取代码，执行代码风格检查、安全漏洞扫描（SAST）。
- 构建阶段：编译源代码，生成可部署的制品（二进制、容器镜像、安装包）。此阶段是制品签名的第一个锚点。
- 单元测试与集成测试：运行自动化测试套件，验证代码逻辑与组件交互。
- 制品签名与推送：对构建产物进行数字签名，并将签名后的制品推送至制品仓库（如 Harbor、Nexus）。
- 部署前签名验证：在部署到目标环境前，对制品签名进行二次校验，确保未被篡改。
- 部署与验收测试：将验证通过的制品部署到测试或生产环境，执行冒烟测试或端到端测试。
实践建议： 在 IDP 平台中，建议将“制品签名”和“签名验证”作为独立的流水线阶段，而非嵌入到构建或部署步骤中。这样做可以提升安全审计的可见性，并便于在签名失败时快速定位问题。
2.3 常见 CI/CD 工具对比
当前主流 CI/CD 工具包括 Jenkins、GitLab CI 和 GitHub Actions。三者在架构、配置方式、生态集成和制品签名支持方面存在显著差异。下表从平台工程视角进行对比：
| 对比维度 | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| 架构模式 | Master/Agent 分布式 | Runner 分布式（共享/特定） | Runner 托管 + 自托管 |
| 配置方式 | Web UI + Jenkinsfile（Groovy） | .gitlab-ci.yml（YAML） | .github/workflows/*.yml（YAML） |
| 插件/市场生态 | 极为丰富（1000+ 插件） | 内置功能丰富，少插件依赖 | Actions 市场，社区活跃 |
| 制品签名支持 | 需插件（如 Sign Plugin）或自定义脚本 | 内置 CI/CD 变量 + 自定义脚本 | 通过 Action 或脚本调用签名工具 |
| 密钥管理 | Credentials 插件 + 外部 Vault | CI/CD Variables（支持 Masked） | Secrets（加密存储） |
| 适用场景 | 复杂流水线、多语言、企业级定制 | GitLab 原生生态、DevOps 一体化 | GitHub 生态、开源项目、快速启动 |
安全提醒： 无论使用哪种 CI/CD 工具，签名私钥的存储必须遵循最小权限原则。建议使用专用的密钥管理服务（如 HashiCorp Vault、AWS KMS）或工具内置的加密变量功能，严禁将私钥明文写入流水线配置文件或代码仓库。
2.4 工具选型建议
在 IDP 平台工程场景下，CI/CD 工具选型需综合考虑团队技术栈、安全合规要求和制品签名链路的集成复杂度。以下为选型决策要点：
- Jenkins：适合已有 Jenkins 基础设施的企业，或需要高度定制化流水线的场景。制品签名可通过 Pipeline 脚本灵活集成，但需额外维护插件和密钥管理。
- GitLab CI：适合采用 GitLab 作为 DevOps 一体化平台的组织。其内置的 CI/CD 变量和 Runner 机制可简化签名密钥的分发，且与 GitLab 容器注册表天然集成。
- GitHub Actions：适合以 GitHub 为核心的开源项目或云原生团队。Actions 市场中有现成的签名 Action（如
sigstore/cosign-installer），可快速实现容器镜像签名。
平台工程视角： 无论选择哪种工具，IDP 平台都应抽象出一层统一的“签名服务接口”，将具体的签名实现与流水线解耦。这样，当底层 CI/CD 工具发生变更时，制品签名链路无需重写，只需适配新的工具适配器即可。