Kubernetes 微服务部署
使用场景: 标准化服务交付的平台工程师
触发：合并到 main
构建：编译服务并运行静态检查
测试：单元测试、契约测试、e2e 冒烟测试
打包：Docker build → 镜像仓库
部署：Helm/Kustomize 到预发，再到生产
监控：Grafana 告警、错误预算燃烧、回滚决策
这样组织的原因: 将镜像创建和部署分开，能明确哪个阶段产生产物、哪个阶段负责推广产物。这种分离是可复现发布的基础。
真实案例
前端 Web 应用流水线
使用场景: 部署 Next.js 或 React 应用的前端团队
Pull Request：lint、类型检查、单元测试
每个 PR 创建 Preview 部署
合并 main：生产构建 + bundle size 检查
部署到 CDN / Edge 平台
部署后：Lighthouse 冒烟检查和错误监控
这样组织的原因: 前端流水线通常比后端更早需要预览环境。把 Preview 部署画成正式阶段，方便产品和设计在合并前审查改动。
移动应用发布流水线
使用场景: 协调应用商店发布的移动端团队
提交 → 构建 iOS/Android 产物
自动化测试：单元、UI、截图回归
内部分发：TestFlight / Play Internal Testing
人工 QA 审批门禁
商店提交和分阶段发布
崩溃监控和回滚/热修分支
这样组织的原因: 移动端发布受应用商店审核和分阶段发布约束。图能让干系人看到这些限制，避免把移动部署误当成网页部署。
Monorepo CI 流水线
使用场景: 希望缩短大型仓库 CI 时间的工程经理
变更检测：识别受影响包
按包并行构建和测试
共享依赖缓存和构建产物缓存
只对受影响服务图运行集成测试
独立部署发生变化的服务
这样组织的原因: Monorepo 流水线的关键是受影响项目检测。把它可视化出来，可以避免每次改动都触发所有任务，让 CI 随仓库增长仍保持可控。
使用技巧
- 清楚展示产物交接：源码变成构建产物，再变成镜像，最后进入部署。
- 明确标出人工门禁，团队才能评估哪些门禁仍然必要。
- 把监控放在部署之后；只到部署就结束的流水线缺少运维反馈闭环。
- 在箭头上标注命令或工具，例如 npm、Docker、Helm、kubectl 或 Terraform。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=cicd
使用这个 CI/CD 流水线模板