系列定位本篇是「阿明餐厅」系列的正传 5。在前传中阿明完成了架构演进在测试策略中建立了质量保障体系。但代码写完了、测试通过了怎么安全、快速地交付到生产环境这就是 CI/CD 与 DevOps 的价值。引言新菜上线手忙脚乱阿明的厨师长研发了一道新菜松露牛肉面想上线试卖。传统流程厨师长写好配方代码写完了→ 找阿明审批人工审核→ 手动更新菜单系统手动部署→ 更新错了系统报错出问题难回滚→ 新菜上线顾客反馈太贵了没有灰度验证。整个过程花了 3 天还出了两次事故。阿明意识到从代码写完到用户用上之间需要一条自动化流水线。这条流水线要解决三个问题自动化减少人工干预、安全出问题能回滚、快速缩短交付周期。第一章持续集成CI—— 代码合并的自动化阿明的技术团队有 5 个人各自开发不同功能。传统流程每个人在自己的分支上开发 2 周合并时冲突不断花 3 天解决冲突合并后才发现代码不兼容。持续集成Continuous Integration, CI的核心是频繁地每天多次将代码合并到主分支并自动运行测试。CI 流水线开发者提交代码git push ↓ 自动触发 CI 流水线 1. 代码检查Lint语法规范、代码风格 2. 单元测试运行所有单元测试 3. 集成测试运行模块间交互测试 4. 构建Build编译代码生成 Docker 镜像 5. 代码覆盖率检查测试覆盖率是否达标 ↓ 全部通过 → 合并成功 | 任一失败 → 合并失败通知开发者CI 的价值与反模式价值说明尽早发现冲突每天合并冲突少容易解决自动化测试每次合并都跑测试保证代码质量快速反馈5 分钟内知道代码是否有问题反模式CI 流水线太慢。阿明最初的 CI 流水线跑一次要 30 分钟。优化后并行执行测试、缓存依赖、只运行受影响的测试缩短到 5 分钟。CI 的核心是自动化 快速反馈。没有 CI持续交付就是空谈。第二章持续交付CD—— 从代码到生产的自动化CI 保证了代码合并后测试通过但怎么把代码部署到生产环境持续交付Continuous Delivery, CD的核心是将部署过程自动化随时可以一键部署到生产环境。CD 流水线CI 通过代码测试通过Docker 镜像构建完成 ↓ 1. 部署到测试环境Staging自动部署运行 E2E 测试 2. 部署到预生产环境Pre-prod自动部署运行冒烟测试 3. 部署到生产环境Production人工审批后自动部署 ↓ 部署完成 → 监控告警观察 15 分钟确认无异常部署和发布分离很多团队认为部署 发布。正确做法部署和发布分离。部署Deploy代码部署到生产环境但用户还看不到发布Release通过特性开关Feature Toggle或灰度策略逐步对用户开放好处部署后先观察 15 分钟确认无异常再发布出问题可以快速回滚影响范围小。这里的特性开关和高峰保卫战的降级策略使用的是同一套 Feature Toggle 基础设施。CD 的核心是自动化 可回滚。没有 CD部署就是一场赌博。第三章灰度发布 —— 新菜先给 1% 顾客试吃阿明研发了一道新菜定价 188 元。如果直接全量上线可能面临顾客觉得太贵差评如潮、系统出问题所有用户受影响、回滚成本高。灰度发布Gray Release的核心是新功能先对少数用户开放验证无问题后再全量开放。灰度发布的策略阶段 1内部测试0%→ 只对内部员工开放 阶段 2小流量灰度1%→ 观察错误率、用户反馈、系统性能 阶段 3中流量灰度10%→ 继续观察 阶段 4大流量灰度50%→ 确认无问题 阶段 5全量发布100%→ 对所有用户开放反模式灰度比例跳跃太大。阿明最初的策略是 1% → 50% → 100%结果 1% 没问题跳到 50% 时系统扛不住。正确做法灰度比例逐步增加1% → 5% → 10% → 25% → 50% → 100%每个阶段观察 15-30 分钟。灰度发布的核心是小步快跑 快速回滚。没有灰度发布就是一场豪赌。第四章蓝绿部署 —— 新旧系统并行一键切换灰度发布是逐步放量但如果新版本有严重 Bug怎么快速回滚传统做法回滚要 10-15 分钟期间用户无法使用。蓝绿部署Blue-Green Deployment的核心是新老版本同时运行通过路由切换流量实现秒级回滚。初始状态 蓝环境Blue运行 v1 版本承接 100% 流量 绿环境Green空闲 部署新版本 绿环境部署 v2 版本运行冒烟测试 切换流量 蓝环境 → 绿环境承接 100% 流量 观察 15 分钟 无问题 → 蓝环境升级为 v2绿环境空闲 有问题 → 流量切回蓝环境秒级回滚价值说明秒级回滚切换 Service selector 即可回滚零停机新老版本并行切换时无感知验证充分绿环境部署后先内部测试确认无问题再切换反模式蓝绿环境资源不足。蓝绿部署需要两套环境成本翻倍。阿明的策略蓝绿环境资源配置一致切换后观察 15 分钟确认无问题再释放蓝环境资源。蓝绿部署的核心是并行运行 秒级切换。没有蓝绿回滚就是一场豪赌。第五章金丝雀发布 —— 用真实用户验证灰度发布和蓝绿部署都是部署策略但怎么知道新版本是否真的更好金丝雀发布Canary Deployment的核心是新版本先对少数真实用户开放通过监控数据判断是否全量发布。金丝雀发布的判断标准金丝雀阶段1% 流量到新版本 监控指标 - 错误率新版本 1%老版本 0.5%✅ - P99 延迟新版本 500ms老版本 450ms✅ - 用户评分新版本 4.5老版本 4.3✅ 判断 所有指标优于或等于老版本 → 进入下一阶段10% 任一指标劣于老版本 → 回滚到老版本金丝雀发布依赖实时监控指标如 P99 延迟、错误率这些指标的设计和告警策略详见《厨房装监控》。没有好的 Metrics金丝雀发布就是盲人开车。反模式金丝雀阶段太短。阿明最初的策略是 1% 流量跑 5 分钟就全量。问题是样本量太小、某些问题如内存泄漏需要长时间运行才暴露。正确做法金丝雀阶段至少 15-30 分钟确保至少 1000 次请求。金丝雀发布的核心是数据驱动 小步快跑。没有金丝雀发布就是盲飞。第六章GitOps —— 基础设施即代码阿明的运维团队有一个问题配置变更难以追踪。运维工程师手动修改 Kubernetes 配置如副本数从 3 改为 5修改后没有记录出问题不知道谁改的、改了什么。GitOps的核心是把基础设施配置存储在 Git 仓库中通过 Git 提交触发自动化部署。GitOps 的流程1. 开发者修改 Git 仓库中的配置文件如 deployment.yaml 2. 提交 Pull Request团队 Review 3. Review 通过后合并到主分支 4. GitOps 工具如 Argo CD检测到 Git 变更 5. 自动将配置同步到 Kubernetes 集群 6. 监控配置变更确认部署成功价值说明版本控制所有配置变更都有 Git 记录可追溯审计合规谁改了什么、什么时候改的一目了然详见安全架构的审计日志自动化同步Git 变更后自动同步到集群减少人工操作反模式GitOps 和手动操作混用。如果团队既用 GitOps 自动同步又有人手动修改集群配置会导致配置漂移。阿明的策略所有配置变更都通过 GitOps紧急情况下可以先手动修改但事后必须同步到 Git。GitOps 的核心是配置即代码 自动化同步。没有 GitOps基础设施管理就是一场混乱。核心总结CI/CD 与 DevOps 的完整旅程无问题有问题代码提交CI 流水线Lint 测试 构建CD 流水线部署到测试/预生产部署策略灰度/蓝绿/金丝雀生产环境监控告警观察 15 分钟全量发布回滚GitOps配置即代码策略核心问题餐厅类比技术实现CI持续集成代码合并后测试通过吗新配方先小批量试做GitHub Actions / JenkinsCD持续交付怎么自动化部署自动化出餐流水线Argo CD / Spinnaker灰度发布怎么逐步放量新菜先给 1% 顾客试吃Nginx / Istio蓝绿部署怎么秒级回滚新旧菜单并行一键切换K8s Service Deployment金丝雀发布怎么数据驱动决策用真实用户反馈判断Istio / PrometheusGitOps怎么管理配置变更菜单变更走审批流Argo CD / Flux一句心法CI/CD 不是工具而是文化。持续集成、持续交付、灰度发布、蓝绿部署、金丝雀发布、GitOps这些实践的核心是自动化、可回滚、快速反馈。没有 CI/CDDevOps 就是空谈。延伸阅读测试策略 —— 测试是 CI/CD 流水线的核心环节自动化测试让持续集成成为可能架构是长出来的 —— CI/CD 的前提是架构已经拆分到可独立部署的微服务高峰保卫战 —— 灰度发布是降级策略的进阶版两者都通过控制流量降低风险厨房装监控 —— 金丝雀发布依赖监控数据判断可观测性是发布决策的基础食安大检查 —— 安全左移在 CI/CD 流水线中集成安全扫描让安全问题尽早暴露给产品经理的重构说明书 —— 重构后的代码同样需要 CI/CD 保障渐进式翻新需要安全的部署策略从厨师到 CEO —— CI/CD 是平台工程IDP的核心能力应该沉淀为团队共享的基础设施当餐厅长出大脑 —— Agent 系统的持续交付模型更新、Prompt 变更都需要安全的部署策略API 设计 —— 部署新版本时API 向后兼容是灰度发布的前提结语阿明从手写菜单到自动化流水线的故事本质上是所有工程团队都要面对的问题怎么安全、快速地交付代码而不是靠人工操作和运气答案是 CI/CD 部署策略 GitOps持续集成保证代码质量持续交付自动化部署灰度/蓝绿/金丝雀降低发布风险GitOps 管理配置变更。下次当你发布代码时不妨问自己我有 CI 流水线吗每次合并都自动跑测试吗我用了灰度/蓝绿/金丝雀吗还是直接全量发布出问题能快速回滚吗回滚流程是自动化的吗配置变更有版本控制吗还是手动修改难以追踪好的 CI/CD不是让发布变快而是让发布变安全。自动化、可回滚、快速反馈这三点是 CI/CD 的核心。← 返回系列导读
从接单到出餐——从阿明的“手写菜单“到自动化流水线，看 CI/CD 与 DevOps 的完整旅程
系列定位本篇是「阿明餐厅」系列的正传 5。在前传中阿明完成了架构演进在测试策略中建立了质量保障体系。但代码写完了、测试通过了怎么安全、快速地交付到生产环境这就是 CI/CD 与 DevOps 的价值。引言新菜上线手忙脚乱阿明的厨师长研发了一道新菜松露牛肉面想上线试卖。传统流程厨师长写好配方代码写完了→ 找阿明审批人工审核→ 手动更新菜单系统手动部署→ 更新错了系统报错出问题难回滚→ 新菜上线顾客反馈太贵了没有灰度验证。整个过程花了 3 天还出了两次事故。阿明意识到从代码写完到用户用上之间需要一条自动化流水线。这条流水线要解决三个问题自动化减少人工干预、安全出问题能回滚、快速缩短交付周期。第一章持续集成CI—— 代码合并的自动化阿明的技术团队有 5 个人各自开发不同功能。传统流程每个人在自己的分支上开发 2 周合并时冲突不断花 3 天解决冲突合并后才发现代码不兼容。持续集成Continuous Integration, CI的核心是频繁地每天多次将代码合并到主分支并自动运行测试。CI 流水线开发者提交代码git push ↓ 自动触发 CI 流水线 1. 代码检查Lint语法规范、代码风格 2. 单元测试运行所有单元测试 3. 集成测试运行模块间交互测试 4. 构建Build编译代码生成 Docker 镜像 5. 代码覆盖率检查测试覆盖率是否达标 ↓ 全部通过 → 合并成功 | 任一失败 → 合并失败通知开发者CI 的价值与反模式价值说明尽早发现冲突每天合并冲突少容易解决自动化测试每次合并都跑测试保证代码质量快速反馈5 分钟内知道代码是否有问题反模式CI 流水线太慢。阿明最初的 CI 流水线跑一次要 30 分钟。优化后并行执行测试、缓存依赖、只运行受影响的测试缩短到 5 分钟。CI 的核心是自动化 快速反馈。没有 CI持续交付就是空谈。第二章持续交付CD—— 从代码到生产的自动化CI 保证了代码合并后测试通过但怎么把代码部署到生产环境持续交付Continuous Delivery, CD的核心是将部署过程自动化随时可以一键部署到生产环境。CD 流水线CI 通过代码测试通过Docker 镜像构建完成 ↓ 1. 部署到测试环境Staging自动部署运行 E2E 测试 2. 部署到预生产环境Pre-prod自动部署运行冒烟测试 3. 部署到生产环境Production人工审批后自动部署 ↓ 部署完成 → 监控告警观察 15 分钟确认无异常部署和发布分离很多团队认为部署 发布。正确做法部署和发布分离。部署Deploy代码部署到生产环境但用户还看不到发布Release通过特性开关Feature Toggle或灰度策略逐步对用户开放好处部署后先观察 15 分钟确认无异常再发布出问题可以快速回滚影响范围小。这里的特性开关和高峰保卫战的降级策略使用的是同一套 Feature Toggle 基础设施。CD 的核心是自动化 可回滚。没有 CD部署就是一场赌博。第三章灰度发布 —— 新菜先给 1% 顾客试吃阿明研发了一道新菜定价 188 元。如果直接全量上线可能面临顾客觉得太贵差评如潮、系统出问题所有用户受影响、回滚成本高。灰度发布Gray Release的核心是新功能先对少数用户开放验证无问题后再全量开放。灰度发布的策略阶段 1内部测试0%→ 只对内部员工开放 阶段 2小流量灰度1%→ 观察错误率、用户反馈、系统性能 阶段 3中流量灰度10%→ 继续观察 阶段 4大流量灰度50%→ 确认无问题 阶段 5全量发布100%→ 对所有用户开放反模式灰度比例跳跃太大。阿明最初的策略是 1% → 50% → 100%结果 1% 没问题跳到 50% 时系统扛不住。正确做法灰度比例逐步增加1% → 5% → 10% → 25% → 50% → 100%每个阶段观察 15-30 分钟。灰度发布的核心是小步快跑 快速回滚。没有灰度发布就是一场豪赌。第四章蓝绿部署 —— 新旧系统并行一键切换灰度发布是逐步放量但如果新版本有严重 Bug怎么快速回滚传统做法回滚要 10-15 分钟期间用户无法使用。蓝绿部署Blue-Green Deployment的核心是新老版本同时运行通过路由切换流量实现秒级回滚。初始状态 蓝环境Blue运行 v1 版本承接 100% 流量 绿环境Green空闲 部署新版本 绿环境部署 v2 版本运行冒烟测试 切换流量 蓝环境 → 绿环境承接 100% 流量 观察 15 分钟 无问题 → 蓝环境升级为 v2绿环境空闲 有问题 → 流量切回蓝环境秒级回滚价值说明秒级回滚切换 Service selector 即可回滚零停机新老版本并行切换时无感知验证充分绿环境部署后先内部测试确认无问题再切换反模式蓝绿环境资源不足。蓝绿部署需要两套环境成本翻倍。阿明的策略蓝绿环境资源配置一致切换后观察 15 分钟确认无问题再释放蓝环境资源。蓝绿部署的核心是并行运行 秒级切换。没有蓝绿回滚就是一场豪赌。第五章金丝雀发布 —— 用真实用户验证灰度发布和蓝绿部署都是部署策略但怎么知道新版本是否真的更好金丝雀发布Canary Deployment的核心是新版本先对少数真实用户开放通过监控数据判断是否全量发布。金丝雀发布的判断标准金丝雀阶段1% 流量到新版本 监控指标 - 错误率新版本 1%老版本 0.5%✅ - P99 延迟新版本 500ms老版本 450ms✅ - 用户评分新版本 4.5老版本 4.3✅ 判断 所有指标优于或等于老版本 → 进入下一阶段10% 任一指标劣于老版本 → 回滚到老版本金丝雀发布依赖实时监控指标如 P99 延迟、错误率这些指标的设计和告警策略详见《厨房装监控》。没有好的 Metrics金丝雀发布就是盲人开车。反模式金丝雀阶段太短。阿明最初的策略是 1% 流量跑 5 分钟就全量。问题是样本量太小、某些问题如内存泄漏需要长时间运行才暴露。正确做法金丝雀阶段至少 15-30 分钟确保至少 1000 次请求。金丝雀发布的核心是数据驱动 小步快跑。没有金丝雀发布就是盲飞。第六章GitOps —— 基础设施即代码阿明的运维团队有一个问题配置变更难以追踪。运维工程师手动修改 Kubernetes 配置如副本数从 3 改为 5修改后没有记录出问题不知道谁改的、改了什么。GitOps的核心是把基础设施配置存储在 Git 仓库中通过 Git 提交触发自动化部署。GitOps 的流程1. 开发者修改 Git 仓库中的配置文件如 deployment.yaml 2. 提交 Pull Request团队 Review 3. Review 通过后合并到主分支 4. GitOps 工具如 Argo CD检测到 Git 变更 5. 自动将配置同步到 Kubernetes 集群 6. 监控配置变更确认部署成功价值说明版本控制所有配置变更都有 Git 记录可追溯审计合规谁改了什么、什么时候改的一目了然详见安全架构的审计日志自动化同步Git 变更后自动同步到集群减少人工操作反模式GitOps 和手动操作混用。如果团队既用 GitOps 自动同步又有人手动修改集群配置会导致配置漂移。阿明的策略所有配置变更都通过 GitOps紧急情况下可以先手动修改但事后必须同步到 Git。GitOps 的核心是配置即代码 自动化同步。没有 GitOps基础设施管理就是一场混乱。核心总结CI/CD 与 DevOps 的完整旅程无问题有问题代码提交CI 流水线Lint 测试 构建CD 流水线部署到测试/预生产部署策略灰度/蓝绿/金丝雀生产环境监控告警观察 15 分钟全量发布回滚GitOps配置即代码策略核心问题餐厅类比技术实现CI持续集成代码合并后测试通过吗新配方先小批量试做GitHub Actions / JenkinsCD持续交付怎么自动化部署自动化出餐流水线Argo CD / Spinnaker灰度发布怎么逐步放量新菜先给 1% 顾客试吃Nginx / Istio蓝绿部署怎么秒级回滚新旧菜单并行一键切换K8s Service Deployment金丝雀发布怎么数据驱动决策用真实用户反馈判断Istio / PrometheusGitOps怎么管理配置变更菜单变更走审批流Argo CD / Flux一句心法CI/CD 不是工具而是文化。持续集成、持续交付、灰度发布、蓝绿部署、金丝雀发布、GitOps这些实践的核心是自动化、可回滚、快速反馈。没有 CI/CDDevOps 就是空谈。延伸阅读测试策略 —— 测试是 CI/CD 流水线的核心环节自动化测试让持续集成成为可能架构是长出来的 —— CI/CD 的前提是架构已经拆分到可独立部署的微服务高峰保卫战 —— 灰度发布是降级策略的进阶版两者都通过控制流量降低风险厨房装监控 —— 金丝雀发布依赖监控数据判断可观测性是发布决策的基础食安大检查 —— 安全左移在 CI/CD 流水线中集成安全扫描让安全问题尽早暴露给产品经理的重构说明书 —— 重构后的代码同样需要 CI/CD 保障渐进式翻新需要安全的部署策略从厨师到 CEO —— CI/CD 是平台工程IDP的核心能力应该沉淀为团队共享的基础设施当餐厅长出大脑 —— Agent 系统的持续交付模型更新、Prompt 变更都需要安全的部署策略API 设计 —— 部署新版本时API 向后兼容是灰度发布的前提结语阿明从手写菜单到自动化流水线的故事本质上是所有工程团队都要面对的问题怎么安全、快速地交付代码而不是靠人工操作和运气答案是 CI/CD 部署策略 GitOps持续集成保证代码质量持续交付自动化部署灰度/蓝绿/金丝雀降低发布风险GitOps 管理配置变更。下次当你发布代码时不妨问自己我有 CI 流水线吗每次合并都自动跑测试吗我用了灰度/蓝绿/金丝雀吗还是直接全量发布出问题能快速回滚吗回滚流程是自动化的吗配置变更有版本控制吗还是手动修改难以追踪好的 CI/CD不是让发布变快而是让发布变安全。自动化、可回滚、快速反馈这三点是 CI/CD 的核心。← 返回系列导读
