PROJECT / 工程实践

GitLab CI/CD 平台与 Runner 治理

将部署过程收敛为明确契约，同时治理 Runner 与平台请求负载。

项目目标

CI/CD 的难点不仅是把命令跑完，还包括发布步骤是否完整、Runner 是否可复用，以及平台自身是否成为瓶颈。本项目将 deploy 的关键步骤保留在单 Job 契约内，并整理部署 Runner，减少跨环境的重复资源占用。

组件与架构

组件包括 GitLab CE、GitLab Runner 与 BuildKitd。部署契约顺序为 validate、build、publish、deploy、verify、cleanup，覆盖校验、构建、发布与结果确认。图示只描述这条已记录的作业流程，不暗示新增审批引擎、队列或调度服务。

GitLab CI/CD 平台与 Runner 治理：脱敏逻辑图validate → build → publish → deploy → verify → cleanup → 交付结果。仅表达功能与流程关系，不是私有部署图。脱敏逻辑图 · 功能与流程validate → buildpublish → deployverify → cleanup交付结果职责关系示意 · 不含内部地址与私有部署细节历史成果与验证边界见下文
脱敏逻辑图：仅展示已记录的功能关系，不代表客户私有部署或当前运行状态。

关键流程

作业先校验输入并构建，发布制品后执行部署，随后验证交付结果并清理。Runner 治理将部署执行收敛到统一资源，利用跨环境无状态复用释放重复主机；平台侧同时观察热门请求量与 P95 延迟，评估治理效果。

工程取舍

单 Job 将部署步骤放在明确的执行边界内，便于识别失败落在哪个环节；相应地，不能把“作业结束”直接当作“服务可用”。展示保留 verify 的独立职责，但不增加现有资料未说明的失败重试或自动回滚机制。

成果与证据口径

2026-09-09 素材收录单仓 409 行、17 个 job 的流水线；既有主页记录 Runner 并发为 5，复用释放 2 台 BCC，平台 P95 从 1.82s 降至 469.50ms。这些属于历史治理样本，未提供统一的持续观测窗口，因此不作为当前平台 SLA 或所有作业的延迟保证。