CI/CD 检查
本页用于检查前后端混合仓库的 CI/CD 是否遵循默认包管理器、构建边界、制品边界与部署边界约定。
检查目标
- 判断前端依赖安装与锁文件是否可复现，而不是依赖个人机器或多套包管理器混用。
- 判断后端
publish、镜像构建与部署步骤是否真正拆清边界。 - 判断多前端 + WebAPI 仓库中的产物汇总与步骤依赖是否稳定可维护。
必查项
- 前端 CI 默认包管理器是否统一为
pnpm。 - 使用
pnpm的前端项目是否提交pnpm-lock.yaml。 - 仓库中是否仍保留会与
pnpm默认口径冲突的package-lock.json。 - 前端安装命令是否使用
pnpm install --frozen-lockfile或等价的冻结锁文件校验方式。 - 当项目使用
node:latest或其他漂移镜像时，是否补充了对应的 pnpm 策略配置，而不是只依赖 lockfile。 - 当依赖链包含需要 install/build script 的包时，仓库是否显式声明允许列表，而不是依赖个人机器缓存、历史
node_modules或旧版 pnpm 行为。 - 多前端仓库中，每个前端应用是否独立成一个构建步骤。
- 前端构建步骤与静态资源汇总步骤是否拆开。
- 后端是否存在独立的
dotnet publish边界。 - 镜像构建步骤是否只消费发布目录，而不是重新编译源码。
- 部署步骤是否与构建、发布、镜像步骤分离。
- 多应用仓库中是否通过
depends_on或等价机制显式写出步骤依赖。
判定标准
- 前端使用
pnpm、锁文件唯一、步骤边界清晰，且后端publish、镜像、部署分离，判定为合规。 - 前端使用
pnpm，且在漂移镜像下仍显式声明 build-script 策略，判定为合规。 - 存量项目保留旧构建方式，但已明确标记偏差范围和迁移计划，判定为已知偏差。
- 若前端同时依赖
pnpm-lock.yaml和package-lock.json作为默认锁文件，判定为不合规。 - 若 CI 已切到新 pnpm 行为，但项目没有补充
pnpm-workspace.yaml或等价 allow 配置，判定为不合规。 - 若后端镜像步骤中重新执行源码编译，或部署步骤中再次构建源码，判定为不合规。
- 若多个步骤写同一发布目录却没有独立汇总边界或显式依赖，判定为不合规。
常见不合规信号
- 文档写
pnpm，但实际.drone.yml仍默认执行npm ci。 - 已迁移
pnpm，仓库里却仍长期保留package-lock.json作为默认锁文件。 - Drone 安装阶段直接报
ERR_PNPM_IGNORED_BUILDS。 - 同一份
pnpm-lock.yaml在旧 pnpm 可以通过，在node:latest对应的新 pnpm 上失败。 - 团队只提交
pnpm-lock.yaml，却没有补充pnpm-workspace.yaml或等价 allow 配置。 - 多个前端应用被塞进同一个构建步骤，失败时无法快速定位是哪一个应用出错。
- 前端构建步骤直接写入后端最终发布目录，多个步骤并行时互相覆盖。
dotnet publish、docker build、docker push和kubectl更新被堆在同一个大步骤里。- 镜像步骤重新读取源码并执行编译，导致发布目录边界失效。
- 部署步骤依赖 YAML 排列顺序而不是显式依赖定义。