持续交付基础摘要

• 手工部署软件
• 开发完成之后才向类生产环境部署
• 生产环境的手工配置管理

• 每次提交代码都可能产生一个可发布的版本

• 为软件的发布创建一个可重复且可靠的发布流程
• 将几乎所有的事情自动化
  • 自动化是部署流水线的前提条件
• 将所有的东西纳入版本控制
  • 需求文档、测试脚本、自动化测试用例、网络配置脚本、部署脚本、数据库创建、升级、回滚和初始化脚本、配置文件、工具链等
• 提前并频繁地做让你感到痛苦的事
• 内建质量
  • 越早发现缺陷，修复成本越低
  • 交付团队必须执行铁一般的纪律：一旦发现缺陷，就要马上着手修复
  • 测试不是一个阶段，测试也不纯粹或主要是测试人员的领域，交付团队的每个人都应该对应用程序的质量负责
• Done 意味着 已发布
• 交付过程是每个成员的责任
• 持续改进
  • 戴明环 ：计划-执行-检查-处理（PDCA）

• 对所有内容进行版本控制
• 频繁提交代码到主干
  • 只有频繁提交代码，你才能享受版本控制所带来的众多好处
  • 一旦将变更提交到版本控制中，那么团队的所有人都能看到这些变更。而且如果使用了持续集成，所做的修改还会触发一次构建
  • 提交代码前运行测试套件（预测试提交），增量式引入变化（每完成一个小功能就提交）
• 使用意义明显的提交注释

一般来说，我们并不赞同在构建或打包时就将配置信息植入的做法，而是应使用相同二进制安装包向所有的环境中部署，以确保这个发布的软件就是那个被测试过的软件。

高效管理的两个基本原则：

• 将二进制与配置信息分离
• 将所有的配置信息保存在一处

环境管理工具：

• Puppet/CFengine/Ansible/Salt
• 虚拟化技术

笔者注：现在来看 Docker 容器化解决了作者提出的很多问题

没有配置管理，根本谈不上持续集成、发布管理以及部署流水线

• 准备工作
  • 版本控制
  • 自动化构建
  • 团队共识
• 一个基本的持续集成系统（如 Jenkins 等）
  • 持续集成是实践而不是工具

• 频繁提交
• 创建全面的自动化测试套件
• 保持较短的构建和测试过程

• 构建失败之后不要提交新代码
• 提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事
• 等提交测试通过后再继续工作
• 回家之前，构建必须处于成功状态
• 时刻准备着回滚到前一个版本
• 在回滚之前要规定一个修复时间
• 不要将失败的测试注释掉
• 为自己导致的问题负责
• 测试驱动的开发