2. CI/CD 服务目录概念
2.1 服务目录的定义
在平台工程的语境下，CI/CD 服务目录是一个经过抽象和标准化的、可被开发者按需发现与使用的持续集成与持续交付能力清单。它并非简单的工具列表，而是一个将底层 CI/CD 基础设施（如 Jenkins、GitLab CI、ArgoCD、Spinnaker）封装为“服务产品”的治理层。
每个服务目录条目通常包含以下核心属性：
| 属性维度 | 说明 | 示例 |
|---|---|---|
| 服务名称 | 面向开发者的可读标识 | “Java 微服务构建流水线” |
| 服务描述 | 功能与适用场景说明 | “适用于 Spring Boot 项目的 Maven 构建 + 单元测试 + 镜像打包” |
| 输入参数 | 开发者需要提供的配置项 | Git 仓库地址、分支名、JVM 参数 |
| 输出产物 | 服务执行后的交付物 | Docker 镜像、Helm Chart、测试报告 |
| SLA / 配额 | 性能承诺与资源限制 | 平均构建时长 ≤ 5 分钟，并发数 ≤ 10 |
| 权限策略 | 谁可以申请、查看、修改 | 仅项目 Owner 可修改流水线定义 |
关键认知： 服务目录的本质是“能力抽象层”。它将底层 CI/CD 工具的复杂性（如 Jenkinsfile 语法、ArgoCD Application 定义）隐藏，对外暴露统一的、符合组织治理规范的接口。
2.2 服务目录在平台工程中的角色
在平台工程的金字塔模型中，服务目录位于开发者体验层与基础设施编排层之间，扮演着“中间治理层”的角色。其核心职责包括：
- 标准化入口： 强制团队使用经过审批的流水线模板，消除“一人一种写法”的碎片化问题。
- 治理边界： 在服务目录中定义安全扫描、制品签名、环境审批等强制性步骤，确保合规性。
- 成本与资源管控： 通过目录条目关联配额（Quota）和预算（Budget），防止 CI/CD 资源被滥用。
- 可观测性聚合： 每个服务目录条目自动关联监控仪表盘，平台团队可以统一查看所有流水线的健康状态。
2.3 服务目录与自助服务的关系
自助服务是平台工程面向开发者的“前台”，而服务目录是支撑这个前台的“货架”。两者之间的关系可以概括为：自助服务是交互界面，服务目录是能力仓库。
具体表现为以下三个层次：
- 发现（Discovery）： 开发者通过自助服务门户浏览服务目录，查看可用的 CI/CD 能力、文档、SLA 和输入输出。
- 请求（Request）： 开发者选择目录条目，填写参数（如 Git 仓库、环境标签），提交创建请求。自助服务门户将请求转发给服务目录引擎。
- 交付（Delivery）： 服务目录引擎根据条目定义，调用底层 CI/CD 工具链自动创建流水线、配置权限、分配资源，并将结果（如流水线 URL、凭证）返回给开发者。
实践案例： 某金融科技公司在其内部开发者平台中，将“生产环境部署流水线”作为一个服务目录条目。开发者通过自助门户申请时，必须选择“合规审批流”（如需要安全团队和架构师审批）。服务目录自动生成 ArgoCD Application 并绑定审批策略，整个过程无需平台团队手动介入。
2.4 服务目录的典型分类
根据 CI/CD 流程的不同阶段，服务目录通常可以分为以下几类：
| 分类 | 典型条目 | 权限关注点 |
|---|---|---|
| 构建服务 | Java Maven 构建、Node.js npm 构建、Golang 交叉编译 | 构建环境隔离、依赖缓存访问权限 |
| 镜像服务 | Docker 镜像构建与推送、Kaniko 无特权构建 | 镜像仓库写入权限、镜像签名密钥访问 |
| 部署服务 | Kubernetes 滚动部署、蓝绿部署、金丝雀发布 | 目标集群 RBAC、审批流程绑定 |
| 安全服务 | SAST 静态扫描、SCA 依赖扫描、容器镜像漏洞扫描 | 扫描结果读取范围、阻断策略配置权限 |
| 环境服务 | 临时测试环境创建、数据库 Schema 迁移 | 环境生命周期管理、资源配额 |
常见误区： 不要将服务目录设计为“所有工具的大杂烩”。每个目录条目都应该有明确的输入、输出和治理策略。条目过多且缺乏标准化，会导致开发者选择困难，反而降低自助服务的效率。