agentleFS
Sign inStart free
peterwangzepeterwangze/software-project-governance/skills/stage-cicd/SKILL.md

stage-cicd

Skill2 starsChanged 5 months agoMITView on GitHub

防护网与CI/CD——流水线、自动化、质量门控。阶段子工作流，可独立使用。

  • Reads credentials

The file

Create a free account to mount
Files
SKILL.md

防护网与 CI/CD — 子工作流

本文件定义"防护网与 CI/CD"阶段的独立子工作流。用户可单独加载本文件执行 CI/CD 配置阶段。

阶段目标

建立持续集成和持续部署的自动化防护网。本阶段的核心产出是"稳定的 CI 流水线"——每次代码变更自动触发构建、测试和校验，质量门禁自动生效。

AI 编程场景特有风险

在 AI 辅助编程项目中，CI/CD 阶段存在以下特有风险：

风险说明缓解方向
AI 配置过于复杂AI 倾向于生成"完备"的 CI 流水线——多阶段并行、矩阵构建、多平台测试，导致 CI 执行时间过长、维护成本高、失败排查困难CI 配置必须从最简单的能用的版本开始；新增步骤必须有"当前需要"的理由
门禁可被绕过AI 可能生成看似完整的门禁配置，但实际存在绕过路径（条件跳过、允许手动合并不检查、规则配置过松）门禁规则必须逐个验证：尝试绕过（故意违规提交）确认门禁确实拒绝
缓存策略不当AI 可能缓存过于激进（使用了过时的依赖、构建产物未清理）或缓存不足（每次都从零构建、CI 耗时过长）缓存策略必须有明确的失效条件；缓存命中率监控；定期全量构建验证
密钥和敏感信息泄露AI 可能在 CI 配置中硬编码密钥、在日志中打印敏感信息、或将 .env 文件暴露给 CI 日志CI 配置必须经过密钥扫描；敏感变量必须使用 CI secrets manager；CI 日志禁止打印环境变量
CI 漂移AI 在不同会话中修改 CI 配置时逐渐偏离原始设计意图，累积矛盾和不一致（同一份 CI 配置中同时存在 3 种不同风格）CI 配置修改必须保持风格一致；重大修改必须在 commit message 中说明原因
门禁指标被优化而非质量被提升AI 可能通过编写无意义的测试来达成覆盖率阈值、调低告警灵敏度来减少告警、或拆分大函数来降低复杂度指标——优化了数字但没有提升实际质量门禁指标必须定期审计有效性——覆盖率增长但缺陷发现率不增长 = 门禁被游戏化；审计结果记录到 evidence-log

独立使用时的目标锚定

当本子工作流被独立加载（非通过 main-workflow.md 总入口加载）时，MUST 在执行阶段活动前完成：

  1. 目标确认：读取 .governance/plan-tracker.md，确认项目立项时定义的量化成功标准
  2. 偏离检查：对照成功标准，确认 CI/CD 覆盖范围与项目质量目标一致。如发现偏离，MUST 先记录到 .governance/decision-log.md 再继续
  3. 质量底线：质量门禁必须覆盖核心路径且不可被绕过（参考 profile 质量要求）

进入条件

  • 测试阶段已完成（G7 通过）
  • 有基础 CI 配置（G4 阶段已建立）

活动清单

1. CI 流水线强化

活动描述交互边界企业实践
补全测试步骤单元测试 + 集成测试 + 回归测试全部纳入 CI自动执行[Google] CI 必须覆盖所有测试类型——不在 CI 里的测试等于不存在
补全静态分析lint + type check + 代码规范检查 + 安全扫描自动执行[Google] 静态分析在 CI 中零容忍——警告即错误
配置构建缓存加速 CI 执行：依赖缓存、构建产物缓存、测试结果缓存自动执行[ByteDance] CI 速度 = 开发效率——慢 CI 会让开发者绕过它
配置并行执行可并行的步骤拆分并行（lint 和 test 同时跑），缩短反馈时间自动执行[Google] 快速反馈是 CI 的核心价值——超过 10 分钟的 CI 会被绕过
验证 CI 稳定性最近 5 次运行成功率 ≥ 80%；失败原因分类（代码问题 vs CI 环境问题）需 CI 环境执行[Google SRE] CI 失败必须有明确分类——是代码烂还是 CI 烂

2. 质量门禁配置

活动描述交互边界企业实践
定义门禁规则覆盖率阈值、lint 零容忍、安全扫描无高危、依赖无已知漏洞自动执行 → 需用户确认[华为 IPD] 门禁规则量化——每个规则有具体数字而非"尽量好"
门禁生效验证每个门禁规则逐个验证：尝试违规提交 → 确认被拒绝自动执行：生成违规测试 → 需 CI 环境执行[华为蓝军] 门禁不是"配置了就生效"——要故意违规验证
配置失败通知门禁不通过时通知相关人员（提交者 + reviewer）需用户输入：通知渠道[Google] 失败通知必须即时且信息充分——让提交者能自行修复
配置门禁绕过策略紧急情况下的门禁绕过流程：谁可以绕过、需要什么审批、事后必须补什么需用户确认[Amazon] 门禁可以被绕过但必须有记录——每次绕过都是一次事后审计

3. 自动化测试套件

活动描述交互边界企业实践
核心路径自动化核心功能路径的自动化测试，覆盖关键业务场景自动执行[Google] 核心路径覆盖率必须 100%——用户最常用的路径不能手动测
回归测试套件每次变更自动运行的回归测试，覆盖已修复的 bug自动执行[Google] 每个已修复的 bug 必须有对应的回归测试——同一个 bug 不会出现两次
覆盖率报告自动生成并作为门禁依据；区分行覆盖率和分支覆盖率自动执行[Google] 覆盖率报告自动生成并在 CI 中可见；覆盖率下降 = 门禁失败
不稳定测试管理标记并隔离 flaky tests（不稳定测试），防止其阻塞 CI 但不让其丢失自动执行[Google] flaky test 自动重试 N 次后隔离，但保留修复任务

4. 部署流程文档化

活动描述交互边界企业实践
编写部署文档部署步骤、环境要求、回滚方案、常见问题自动执行[Amazon] 部署文档必须由实际执行过的命令生成——能跑出来的才写进去
部署自动化部署脚本或 CI 部署步骤，一键部署自动执行[Google SRE] 部署必须是可编程的——手动步骤是事故的温床
验证部署可执行在测试环境中实际执行一次部署流程，确认文档步骤可执行需 CI 环境执行[Amazon] 不在测试环境跑过的部署文档不叫文档——叫草稿
环境差异文档化开发/测试/生产环境的差异显式列出（配置、数据、权限）自动执行[Google SRE] 环境差异必须显式可见——"生产环境不一样"不是意外发现

5. 持续监控与告警接入

活动描述交互边界企业实践
接入关键监控指标错误率、延迟（P50/P95/P99）、可用性、资源使用率接入监控系统自动执行[Google SRE] 4 大黄金信号是监控的最低配置——缺一不可
配置告警规则定义告警阈值、通知渠道、告警升级路径（warning→critical→page）需用户确认：阈值和通知渠道[Google SRE] 告警必须有明确的严重级别和升级路径——不是所有告警都需要半夜叫醒人
部署后自动验证每次部署后自动执行冒烟测试和关键路径验证，确认服务正常自动执行[Amazon] 部署后自动验证——不靠"应该没问题"
定义自动回滚条件错误率超阈值、延迟超阈值、关键路径验证失败 → 自动触发回滚需用户确认：回滚阈值[Google SRE] 自动化回滚比手动回滚快 10 倍——人工判断是回滚延迟的根本原因

产出物标准

产出物格式要求质量标准企业实践来源
CI 配置流水线定义文件 + 门禁规则文件稳定运行（成功率 ≥ 80%）；门禁不可绕过（已通过违规测试验证）[Google] + [华为]
质量门禁门禁规则文件 + 绕过流程文档每个规则可量化判定；绕过有记录和审计[华为 IPD] + [Amazon]
自动化测试套件覆盖核心功能路径 + 已修复 bug 的回归测试核心路径覆盖率 100%；flaky tests 已隔离[Google]
部署文档步骤可执行 + 环境差异说明在测试环境验证通过；有具体命令和验证方式[Amazon] + [Google SRE]

退出条件

  • CI 流水线稳定运行（最近 5 次成功率 ≥ 80%）
  • 自动化测试覆盖核心路径（核心路径覆盖率 = 100%）
  • 质量门禁生效（每个门禁规则通过违规测试验证）
  • 部署流程已文档化且在测试环境验证通过
  • CI 平均反馈时间 ≤ 10 分钟

Gate 映射

本阶段对应 G8 — 防护网就绪。

Gate 检查项对应活动判定标准自动化判定
CI 流水线是否稳定运行？CI 流水线强化最近 5 次运行成功率 ≥ 80%可自动：解析 CI 运行记录
自动化测试是否覆盖核心路径？自动化测试套件核心路径列表与设计文档功能模块对应，覆盖率 ≥ 阈值可自动：覆盖率报告解析 + 功能模块对照
质量门禁是否生效？质量门禁配置每个门禁规则通过违规测试验证，不可绕过半自动：规则文件存在可自动；绕过验证需人工确认
部署流程是否文档化且可执行？部署流程文档化部署文档在测试环境验证通过，步骤可执行半自动：文档存在可自动；可执行性需验证记录
CI 反馈时间是否可接受？CI 流水线强化平均反馈时间 ≤ 10 分钟可自动：解析 CI 执行时间
flaky tests 是否已管理？自动化测试套件不稳定测试已标记隔离，有修复任务可自动：检查 flaky test 标签 + 关联任务

企业实践溯源

本子工作流的设计参考了以下企业实践，每条实践已映射到具体活动步骤：

企业核心实践映射到本工作流
GoogleCI 覆盖所有测试类型 + 零容忍静态分析CI 流水线强化→lint/type check/安全扫描全部纳入 CI
Google快速反馈（≤10 分钟）CI 流水线强化→并行执行；退出条件→CI 反馈时间 ≤10 分钟
Google100% 核心路径覆盖 + 回归测试保底自动化测试套件→核心路径覆盖率 100%；每个 bug 有回归测试
GoogleFlaky test 隔离自动化测试套件→不稳定测试标记隔离，不阻塞 CI
Google SRE部署可编程 + 环境差异显式化部署流程文档化→部署必须自动化；环境差异文档化
Amazon门禁绕过有记录和审计质量门禁配置→紧急绕过流程 + 事后审计
Amazon实际执行过的才写进文档部署流程文档化→在测试环境验证通过后才算文档完成
华为IPD 门控量化评分质量门禁配置→每个规则有具体数字，不可模糊通过
华为蓝军验证（门禁违规测试）质量门禁配置→故意违规确认门禁确实拒绝
ByteDanceCI 速度 = 开发效率CI 流水线强化→缓存 + 并行；慢 CI = 被绕过的 CI

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free