《持续交付：发布可靠软件的系统方法》笔记

 《持续交付：发布可靠软件的系统方法》
Jez Humble, David Farley
乔梁 译

软件交付的原则：
为软件的发布创建一个可重复且可靠的过程
将几乎所有事情自动化
把所有的东西都纳入版本控制
提前并频道地做让你感到痛苦的事情
內建质量（一旦发现缺陷，马上着手修复）
“DONE”意味着已发布
交付过程是每个成员的责任
持续改进

推荐的实践：
频繁提交代码到主干
使用意义明显的提交注释
每次修改都应该触发反馈
创建全面的自动化测试
保持较短的构建和测试过程
构建失败后不要提交新代码

极限编程实践（持续集成，测试驱动，重构）
若违背架构原则，就让构建失败
若测试运行变慢，就让构建失败
若有编译警告或代码风格问题，就让测试失败

只生成一次二进制包
对不同环境采用同一部署方式
对部署进行冒烟测试
向生产环境的副本中部署
每次变更都要立即在流水线中传递
只要有环节失败，就停止整个流水线

为部署流水线的每个阶段创建脚本
使用同样的脚本向所有环境部署
确保部署流程是幂等的（Idempotent）

确保验收测试一直处于通过状态

真正执行部署操作的人应该参与部署过程的创建

将新功能隐蔽起来，直到它完成为止
所有修改都是增量式的
通过抽象来模拟分支

版本控制的分支管理：
一般实践是按功能特性或团队创建分支（团队通常也是代表不同功能特性），在分支上进行开发，然后合并回主干，确保主干一直可发布。
本书推荐基于主干进行开发，确保所有代码被持续集成，避免“合并地狱”。
只为发布创建分支。

场景：需要开始做新功能，而当前发布版本正在测试或准备部署当中，同时测试团队希望能够在当前发布中修复缺陷，但不要影响正在进行当中的新功能开发。
一旦发布频率达到了一定频度（比如一周一次左右），那么按发布创建分支的策略就没必要了。在这种情况下，发布一个新版本要比在已发布的版本中打补丁更容易，成本更低。

无论哪种情况，分支中的修改必须尽可能频繁地合并回主干。