CI/CD 与自动化

为什么要在意这条流水线

当团队迭代速度加快，测试、静态检查和构建往往容易被简化，低质量代码一旦到达生产环境，排查成本会成倍放大。这个技能的目标是建立一条不妥协的质量门禁流水线，确保任何变更在合并前都经过自动化验证，并让 CI 失败的结果直接反馈到开发环节。

技能如何工作

• Shift Left：在流水线最早期执行检查，lint 和静态分析先跑，测试再跟进，之后才进入 staging 和生产。
• Faster is Safer：小批量、高频率发布更容易定位问题。3 个变更的部署远比 30 个变更更容易回滚。
• 质量门禁：lint、类型检查、测试、构建、审计一个都不能少，失败即修复，不要用跳过或关闭规则来蒙混过关。
• GitHub Actions：提供基础 CI、带数据库集成测试的流水线和 E2E 测试示例；敏感信息通过 GitHub Secrets 注入，避免硬编码。
• Agent 反馈闭环：CI 失败时，将错误日志和结构化信息返回给智能代理，自动修复或提示下一步操作。
• 部署策略：支持 preview deployments、feature flags、canary 发布、分阶段 rollout，以及每次部署都预留回滚路径。
• 环境隔离：CI 环境绝不使用生产密钥，测试凭据单独存放。
• Build Cop：指定专人负责保持 CI 绿色，构建损坏时由其修复或回退，而非原提交者。
• CI 优化：当流水线超过 10 分钟，按缓存、并行化、拆分等顺序优化，而不是跳过检查。

适用边界与注意点

适用于新项目 CI 搭建、现有流水线补充检查、部署管道配置和 CI 失败排查。注意不要因为一次失败就禁用测试；不要绕过分支保护；不要在代码或配置中写入密钥。始终确保部署可回滚，并定期清理遗留的 feature flag。