新服务接入统一 CI
- 1确定分支与目标环境
- 2接入固定模板
- 3分配 Runner
- 4配置最小身份
- 5MR 与受保护分支验证
先确定服务职责、构建上下文和发布目标，再选择验证、构建及发布 Runner。云身份按区域和环境配置，共享模板以固定版本引用；分别验证 MR 不触发发布、受保护分支能够构建，以及发布任务仅能访问指定目标。
Skip to content
跳到项目内容制品晋级与发布信任边界01 / 01 验证、测试与生产 Runner 分权，构建和部署承担不同职责；发布、回滚与运行验收绑定精确制品。
项目速览
业务背景
多服务和模型项目需要稳定的构建、测试与发布流程。项目围绕自托管 GitLab、共享 CI 模板、隔离 Runner、不可变制品和运行观测建立研发基础设施，同时维护代码镜像与服务状态页。
负责范围
- 可信共享模板与审查门禁
- Runner 信任区与发布身份
- 应用与模型制品
- 真实业务验收与回滚
31.4 / 31.6 秒
生产部署 / 回滚
网关同一镜像 digest 从测试晋级生产；测试环境完整的发布、回滚、再发布 180 秒。
332 → 0.43 秒
构建排队
Runner 按服务拆分后，静态页发布排队时间的单次对照。
553 → 325 秒
企业服务发布
单次对照；镜像构建作业本身没有变快，收益来自排队与流程调整。
01
核心业务
平台 CI 面向多服务与模型工程，统一代码验证、镜像构建和环境发布。应用代码更新频繁，模型权重体积大且更新节奏不同；国内与海外环境又使用不同云身份、镜像仓库和集群，单份流水线无法依靠共享管理员权限覆盖所有任务。
设计围绕三个问题展开：谁有权执行，实际发布的是哪个制品，发布后如何判断业务可用。MR 验证、测试发布和生产发布按信任区隔离；共享模板固定版本；部署验收把真实调用和精确回滚纳入流程。
- 01可信审查
- 固定版本的共享模板组织静态检查、回归与密钥扫描，保留人工代码审查；AI 审查节点 2026-10-08 起停用。
- 02构建与制品
- 源码 SHA 与镜像 digest 对应，模型底座和业务运行镜像分开维护，控制并行构建的资源争用。
- 03环境交付
- 受保护分支选择对应 Runner 与环境身份，测试验收后的提交和制品再晋级。
02
技术栈
- 验证与审查
- GitLab CI按服务隔离的 Runner受保护分支人工审查密钥扫描
- 制品与发布
- DockerRegistryimage digestKubernetes共享 CI 模板
- 区域身份
- AWS EKS / ECR腾讯云 TKE / TCR受保护分支
- 运行验收
- PrometheusGrafanaBlackbox业务冒烟日志
03
系统架构与部署
审查入口
GitLab MR / 固定版本共享模板业务仓库接入可信的服务端审查入口，模板自身按不可变版本发布。
执行身份
验证 / Builder / Publisher RunnerMR 无生产写入权限；构建身份负责制品，发布身份仅操作指定区域和环境。
运行目标
Registry / Kubernetes / 模型资产代码镜像与模型底座分开，目标部署记录 digest，环境配置与发布锁显式管理。
验收侧
真实 API / Prometheus / Blackbox / 日志部署状态、公开请求与业务记录分别核对，故障后检查恢复状态。
04
核心业务链路
同一制品完成测试与晋级
- 1源码 SHA
- 2构建 digest
- 3测试 rollout
- 4业务冒烟
- 5精确晋级
- 6观测
构建结果记录来源和不可变 digest，测试环境使用该制品验证。生产推广沿用已验收制品；出现问题时按旧 digest 与对应配置恢复，避免回滚时重新构建得到不同内容。
模型更新的真实业务验收
- 1模型资产校验
- 2模型底座 / 运行镜像
- 3模型就绪
- 4公网推理
- 5失败恢复
权重留在资产存储，模型与代码按不同节奏发布。模型加载完成后继续执行实际业务请求：历史部署曾在 modelReady 后出现公网 504，因此 readiness 不能作为唯一通过条件。该类故障记录推动增加有界的公开就绪检查，候选改动与已部署行为分别记录。
05
关键机制与取舍
01审查代码与发布权限分开
- 约束
- 来自 MR 的代码与 CI 定义不能自然获得生产云凭据。
- 做法
- 验证、构建与发布按 Runner 信任区分离，结合受保护分支、固定模板和环境身份限制执行。人工审查对应精确源码版本，审查后仍执行既有回归与凭据检查。
- 效果
- 审查边界在流水线运行阶段继续有效，审批不等于跳过技术验证。
02将业务成功纳入发布合同
- 约束
- Pod Ready、页面可达和流水线成功分别只证明部分链路正常。
- 做法
- 按服务检查 rollout、模型加载、实际接口、认证与账务关联，再独立核对部署 digest 和回滚结果。验收失败保留失败状态与恢复证据，不因恢复旧版本而把新版本发布标为成功。
- 效果
- 发布结果能够解释“部署成功但业务失败”，恢复也有准确的制品归属。
03合并与生产变更解耦，排队不再拖慢发布
- 约束
- 主分支合并即自动发布生产，代码合并和生产变更绑在一起；多个服务共用 Runner，发布常在排队中等待。
- 做法
- 海外主分支只准备制品，生产部署、回滚和再发布改为手动触发；国内测试分支自动发布、生产分支手动晋级，使用独立发布身份。Runner 按服务拆为独立进程和配额，重复的 Go 门禁合并为一次并加缓存。
- 效果
- 单次对照：静态页发布排队 332 → 0.43 秒、总耗时 507.7 → 101.8 秒；企业服务发布 553 → 325 秒；合并门禁 601.6 → 399.9 秒，同一合并请求命中缓存后 182 秒，新合并请求首次仍需约 620 秒。国内生产整体回归尚未通过。
06
AI 协作开发
CI 模板曾经包含一道严格的 AI 代码审查门禁，10 月 8 日从全部流程移除；确定性的检查全部保留。
- 曾经的设计
严格的 AI 审查门禁
审查完整 diff，中等及以上问题阻止合并；模型失败、输出不完整或过期也阻止；误报只能通过受保护、与问题哈希绑定的说明豁免，业务合并请求不能给自己豁免。
- 规则
不要重试到模型同意
审查结论不随重试改变口径；上线前用故意写入除零错误的合并请求验证门禁能拦住问题。
- 现状
保留确定性门禁
六个项目切换到不含 AI 任务的模板，单元测试、密钥扫描、受保护分支、生产手动发布和 Runner 隔离全部保留，历史审查报告留档。
移除后不默认重新启用 AI 审查；需要时作为审查前的提示，而不是阻止合并的硬门禁。
07
阶段成果
- 形成多服务可复用的 CI 合同、可信审查入口与区域发布身份。
- 应用与模型独立组织制品，验收和回滚对应到实际运行版本。
继续浏览
别急，先让缓存热一下。