DevOps 持续交付-笔记
本文档整理自极客时间《持续交付》专栏（40讲全），系统性地涵盖了从代码管理、环境治理、自动化构建到发布监控的完整链路。
第01讲 持续交付到底有什么价值？
- 核心定义
- 持续集成 (CI)：从编码到构建再到测试的反复持续过程。
- 持续部署 (CD)：将可交付产品，快速且安全地交付用户使用的一套方法和系统。
- 持续交付：包含持续集成、测试自动化以及持续部署，囊括开发、测试、部署、运维、运营等等。
- 持续交付的隐性价值
- 对 CTO、Team Leader、产品经理、程序员而言：涉及技术选型、标准落地、部门协作、知识传承、关注业务、节奏平稳、提高工作效率和质量。
- 评估与架构
- 如何评估持续交付的价值。
- 常见的持续交付平台架构：
第02讲 影响持续交付的因素有哪些？
- 影响因素
- 组织和文化因素
- 流程因素
- 架构因素
- 核心原则
康威定律：组织结构决定软件架构。
第03讲 持续交付和 DevOps 是一对好基友
- 认识 DevOps
- 一组技术：包括自动化运维、持续交付、高频部署、Docker 等。Docker 的出现正是为了解决 DevOps 所提倡的“基础设施即代码 (IaC)”。
- 一个职能、一种文化、一种组织架构。
- 核心总结
- DevOps 本质其实是一种鼓励协作的研发文化。
- 持续交付与 DevOps 所追求的最终目标是一致的：快速向用户交付高质量的软件产品。
第04讲 一切的源头，代码分支策略的选择
- 分支策略
- 主干开发 (Trunk Based Development, TBD)
- Google 和 Facebook 都在用。
- 特性：没有 feature branch，全员在主干开发，减少合并麻烦。
- Feature Toggle (特性切换)：保证未成熟功能不被发布。
- 注意风险：特性切换过多会导致逻辑混乱、代码脆弱、难测试/维护、难提供技术支持且不安全。
- 风险点：特性切换会将未经测试的代码引入生产环境，问题可能无意间暴露。
- 缺点：可能出现“一粒老鼠屎坏了一锅粥”的现象。对个人开发能力要求极高。
- 分支开发 (Branch Model)
- 演进：Git Flow (hotfix, release)
GitHub Flow (Pull Request) GitLab Flow (生产、环境及发布分支)。 - 有利于并行开发，需要流程保证，能保证主干代码质量。
- 演进：Git Flow (hotfix, release)
- 主干开发 (Trunk Based Development, TBD)
第05讲 手把手教你依赖管理
- 管理工具举例
- 操作系统级：CentOS (yum), Debian (apt), Arch (Packman), macOS (Homebrew)。
- 编程语言级：Java (Maven), .Net (nuget), Node.js (npm), Golang (go get), Python (pip), Ruby (Gem)。
第06讲 代码回滚，你真的理解吗？
- 主要方式
- Roll back：回滚到过去的某个版本。
- 新增 Commit：移除对应功能（Revert）。
- 工具注意：谨慎使用
git reset --hard。
第07讲 “两个披萨”团队的代码管理实际案例
- “两个披萨”团队 (Two-Pizza Teams)
- 亚马逊内部实践：团队人数不能多到两个披萨饼还不够吃的地步（约 7 人左右）。
- 核心：团队要小到让每个成员都能做出显著贡献，相互依赖，有共同目标和统一成功标准。
- 协作模式：使用
GitLab + Issue + Feature Branch开发模式。
第08讲 测试环境要多少？从现实需求说起
- 核心问题：测试环境结构与好的测试环境标准。
- 环境模型 (五套环境标准)
- 开发环境：供开发人员使用。
- 功能测试环境：供 QA 验证。
- 验收测试环境：供产品经理、测试人员最终确认。
- 预发布环境：进入生产网络，共享生产基础设施（数据库等）。
- 实现方式：a. 金丝雀发布（真实流量机器）；b. 一组不接入真实流量的机器。
- 生产环境：真实用户访问环境。
第09讲 测试环境要多少？从成本与效率说起
- 成本三要素：机器资源成本、管理成本（配置/数据）、流程成本（沟通/测试）。
- 效率提升
- 在抽象公共环境基础上，通过泳道 (Swimming Lane) 隔离相关测试应用。
- 降低配置复杂度。
第10讲 让环境自己说话，论环境自描述的重要性
- 核心痛点：环境配置非常复杂，直接影响环境治理能力，进而影响持续交付能力。
- 环境自描述
- 通过环境标准化，利用自描述文件让环境能讲清楚自己的作用、依赖及状态，而非依赖外部零散配置。
第11讲 “配置”是把双刃剑，带你了解各种配置方法
- 配置分类：构建时配置、打包时配置、运行时配置。
- 配置中心：推荐方案，如携程开源的 Apollo。
- 痛点：如何有效回滚配置。
第12讲 极限挑战，如何做到分钟级搭建环境？
- 主流工具：Puppet、Chef、Ansible、SaltStack 等。
- 提速手段：并行处理、缓存池。
第13讲 容器技术真的是环境管理的救星吗？
- 容器价值：重新定义了交付标准，统一了软件环境与代码，交付产物即镜像。
- 不可变基础设施 (Immutable Infrastructure)
- 理念：任何变化（代码、环境、配置）均需重新制作镜像，产生新版本。
- 代价：原本简单的修改（如装个 curl）也需要重跑镜像构建流程。
第14讲 如何做到构建的提速，再提速！
- 提速方法
- 硬件升级：SSD、大内存。
- 搭建私有仓库：
- CentOS (yum):
createrepo - Java (Maven):
Nexus - Node.js (npm):
cnpm - Python (pip):
pypiserver - 代码仓库:
GitLab - Docker 镜像:
Harbor
- CentOS (yum):
- 本地缓存：充分利用工具缓存机制。
- 流程规范：通过异步方式解决旁支流程执行。
- 工具优化：根据实际情况发挥构建工具特性。
第15讲 构建检测，无规矩不成方圆
- 检测项
- 环境：软件版本、编译工具版本、操作系统一致性。
- 依赖：依赖关系及版本冲突检查。
第16讲 构建资源的弹性伸缩
- CI 工具：Travis CI、Circle CI、Jenkins CI。
- Jenkins Master 高可用
- 单 Master 易成为瓶颈。
- 解决方案：对 Jenkins 封装，实现自定义高可用多 Master 架构。
- Slave 弹性伸缩：利用容器化技术与 Kubernetes (K8s) 结合，动态调度资源。
第17讲 容器镜像构建的那些事儿
- 仓库：Docker Hub。
- 构建方式（核心区别在于使用宿主还是容器独立的 docker daemon）：
- DooD (Docker Out Of Docker)
- DinD (Docker In Docker)
第18讲 如何做好容器镜像的个性化及合规检查？
- 个性化方法：1. 自定义环境脚本；2. 平台化环境选项与服务集市；3. 自定义镜像发布。
- 合规检查：比对各个 Layer，检查是否包含官方 Base 镜像 Layer。
- 合规工具：CoreOS Clair, Docker Security Scanning, Drydock 等。
第19讲 发布是持续交付的最后一公里
- 部署 (Deploy) vs 发布 (Rollout)
- 部署不代表发布（如旁路运行 dark launch）。
- 发布系统期望：易用、快速、稳定、容错，且具备迅速回滚能力。
- 单节点部署流程 (5步)
- Download：下载新版本，不执行覆盖。
- Markdown：通知上游，自己进入暂停服务状态。
- Install：执行 load 变更，重启服务。
- Verify：验证健康状况及预热。
- Markup：通知上游，服务恢复正常。
- 集群部署方式
- 蓝绿发布：发布新版到新集群，验证后将全量流量切入，无异常则下线老版本。
- 滚动发布：分批次更新集群机器，验证通过后接回流量，直到全部遍历。
- 金丝雀发布：挑选特定服务器或特征用户进行小规模更新验证。
- 灰度发布系统：如携程开源的 Tars。
第20讲 Immutable！任何变更都需要发布
- 前提：应用必须是无状态 (Stateless) 的。
- 价值：保证环境、顺序、配置在测试与生产环节的高度一致性。
第21讲 发布系统一定要注意用户体验
- 1-2-3-4-5-6 原则
- 1 张页面展示发布信息（全面且精准）。
- 2 个操作按钮简化使用（如：发布、中断、重试）。
- 3 种发布结果（成功、失败、中断）。
- 4 类操作选择（开始、停止、回退、重试）。
- 5 个发布步骤（见第 19 讲单节点流程）。
- 6 大页面内容区：集群、实例、日志、历史、批次、操作区。
第22讲 发布系统的核心架构和功能设计
- 核心组件：DeploymentConfig, Deployment, DeployBatch, DeployTarget。
- 进阶能力：发布状态流转、服务降级、熔断机制。
第23讲 业务及系统架构对发布的影响
- 考虑因素：增量 vs 全量、单机单应用 vs 单机多应用。
- 机制设计：如何控制 Markup/Markdown、检查/预热/点火机制（点火即 Verify 自动化）。
- 堡垒流量：软负载 + Header 附加堡垒标记，确保堡垒机流量在专用链路流转。
第24讲 如何利用监控保障发布质量？
- 监控五维度
- 用户侧：访问速度和真实结果。
- 网络：CDN 与核心网络。
- 业务：核心业务指标波动。
- 应用：服务调用链 (Tracing)。
- 系统：基础设施、VM 及 OS。
第25讲 代码静态检查实践
- 测试管理范畴：静态检查、破坏性测试、Mock 与回放。
- 平台与工具
- 平台：SonarQube。
- 工具：FindBugs、PMD、Checkstyle。
第26讲 越来越重要的破坏性测试
- 维度：单点维度、系统维度（压测、暴力测试、阻断链路）。
- 混沌工程：Netflix 开源的 Chaos Monkey。
第27讲 利用 Mock 与回放技术助力自动化回归
- 测试难点：数据准备/清理、分布式依赖、用例仿真度。
- 核心方案
- Mock
- 原理：用模拟对象代替难以剥离的复杂依赖对象。
- 类级 Mock：Mockito, EasyMock (常用于单测)。
- 服务级 Mock：Weir Mock, Mock Server。
- 回放 (Replay)
- 原理：记录生产环境真实操作并在测试环境回放。
- 拦截方案：
- SLB 统一拦截：易影响路由服务。
- 集群扩容独立服务器：利用软交换转发请求，结合云平台弹性，风险低。
- 回放模式：按原始时间间隔顺序回放；压缩时间间隔进行压力回放。
- Mock
第28讲 持续交付为什么要平台化设计？
- 五大核心部分：配置管理、环境管理、构建集成、发布及监控、测试管理。
- 平台化理念：自己搭台，让其他人唱戏。
- 核心模块联动
- 代码管理
审核、扫描、分支管理。 - 集成编译
依赖管理、单测、打包。 - 环境管理
资源申请、配置、路由。
- 代码管理
- 原则：标准先行，定义各个模块交付产物的标准。
第29讲 计算资源也是交付的内容
- 云计算：基础设施的交付同样需要纳入流水线。
第30讲 持续交付中有哪些宝贵数据？
- 系统优化：通过数据说话，从数据角度寻找优化方向。
- 三大指标：稳定性指标、性能指标、持续交付能力成熟度指标。
第31-33讲 移动 App 的持续交付进阶
- 模式：发布快车模式 (Release Train)，定期发车。
- 交付效率优化
- 流程优化：开发、构建、测试、发布全链路。
- 构建优化：扁平化依赖管理、二进制交付。
- 发布优化：测试用户集定期更换，避免测试疲劳。
第34讲 快速构建持续交付系统（一）：需求分析
- 模块具体需求
- 代码/配置：Code Review、静态扫描。
- 构建/集成：支持 Jar/War/Docker/App，版本可追溯，支持高并发。
- 打包/发布：统一部署标准，多产物支持。
- 自动化测试：TestNG 驱动，实现全自动。
第35-37讲 快速构建实战：选型与搭建
- 代码管理：GitLab (Omnibus 安装) + SonarQube。
- 集成打包：Jenkins (Maven + Pipeline)。
- 自动部署：Ansible (Tower) 或 Spinnaker (Netflix 开源，解耦云平台)。
第38讲 持续交付特别放送：答疑解惑
- 数据库发布与回滚
- 准则：1. 只能新增字段，不能删除或修改已有字段，且新增字段必须有默认值。2. 必须修改结构的场景由 DBA 操作，不纳入自动化流程。
- 不可变性：K8s + Docker 的最佳实践。
- 破坏性测试：DR 演练 (灾难恢复)。
- GitLab HA：通过 Sharding 解决大规模存储问题。
第39讲 持续交付高效学习指南
- 推荐书籍：《持续交付：发布可靠软件的系统方法》、《凤凰项目》。
- 建议：通读官方文档。深入理解开源软件的设计原理，而不只是使用它们。
第40讲 结束语：越痛苦的事，越要经常做
- DevOps 工程师的五大特质 (五痛)
- 比架构师懂得多：需要全局视野。
- 比开发人员动作快：自动化是核心。
- 比 QA 团队眼睛尖：洞察潜在质量风险。
- 比运营人员“心脏大”：顶得住压力，受得住委屈（如处理生产事故）。
- 比产品经理还会“吹”：擅长系统推广与包装，因为需要向团队推广 CI/CD 文化和工具，讲 PPT 做演示是必修课。