1. CD介绍
1.1 要点
什么是CD? 以一种可承受的方式，安全、快速地落实变更的能力
为什么要CD? 无痛release，降低风险；加速进入市场；提高软件质量和稳定性；减少软件开发的成本；让客户和员工开心；快速获得反馈
许多Agile项目的问题，在原来的water fall中增加了scrum: (PMO+finance)研究+批准->设计+计划; (‘Agile’ team迭代)分析、开发、测试+演示; （Centralized QA）集成+QA->(IT运维)Release&运维。最后一公里的集成测试和Release仍然痛苦, CD就是要铲除最后一公里，每个迭代(甚至在迭代之内)都为用户产出产品
amazon.com 2010年时，在工作日平均11.6秒做一次部署，最高峰一小时做了1079次部署，平均每次部署10000台，最高每次部署30000台。
要点：提升质量；每次处理更小的单元；重复的工作交给电脑，人来解决问题；持续改进；人人需对产出负责
1.2 价值
拥有更高效、能快速变化IT能力的组织在市场上更有竞争力。
你的组织多长时间能将一个单行代码的变更部署到生产环境？你们可以以一个可重复、可靠的基础完成部署
Lead time: 能多快还原一个服务？能多快发布一个严重问题修复？能多快验证一个特性有价值？
使用了简化、自动化、降低风险的流程，可以保证更频繁的Release。
小的变更，易于判断引起问题的原因
判断价值 -> 假说驱动Delivery：我们相信为XXX开发的YYY特性，将达到ZZZ目标；如果我们能看到市场上XXX信号，我们将知道我们成功
“Online experimentation at Microsoft”，仅有1/3的新特性改进了核心度量
1.3 要素
Architecture 要求系统的可测试性和可部署性；可以快速廉价的在开发机上完成完整测试是否可以Realease，无需复杂的部署流程。
Patterns & practices
Collaboration
要素：配置管理，持续集成，自动化测试
高IT表现(DevOps)：代码、APP配置和系统配置都在一个版本控制系统，高吞吐(自动化)高稳定性(快速回滚)；从日志和监控系统获得失效警告；开发每天将代码merge到主干；开发将大的特性分解成小的、增量的变化；开发和运维团队交流产生双赢结果
莫等到开发结束后才做测试，Check in代码之前就要做测试；每个人都对质量抱有责任，开发、测试、运维
由开发工作站、橡皮鸭和铃构成的简单CI系统。在本地开发->在本地构建并测试->从主干抓取代码并合并->在本地构建并测试->获取橡皮鸭->推送并在服务器构建并测试->（成功）归还橡皮鸭并按铃->（失败）如果短暂的几分钟修复不了，则在主干上回滚代码
不同种类的测试：
- 自动化：UT, 组件测试，系统测试；功能接受测试
- 手工：演示，易用性测试，探索测试
- 自动化/手工：非功能测试(容量，安全，可用性) 对于架构的验证，易尽早开展
1.4 部署管道(Deployment Pipeline)
图中是一个简化版的，部署管道可能很复杂。
自动化测试要尽可能块，尽快反馈测试的结果 
提交阶段：每次check-in都执行；创建release备选；失败则立即修复
接受阶段：package放在artifact repo(如nexus)，而非版本控制中；在类生产环境中做端到端测试，通过提交测试即触发；失败则立即修复
手工阶段：UAT, staging, integration, production；通过按钮流程自服务的部署；推送系统
部署管道经验之谈：仅一次构建你的包，放入repo中后用于各阶段测试直至生产；用同样的脚本、流程、方式部署所有的环境；部署后进行冒烟测试；保持环境一致，拓扑，硬件，系统，软件；如果中间有环节失败了，停止管道。
1.5 案例：HP LaserJet固件部门
除了构建Web服务，CD同样可以用于传统的安装型软件、固件
问题：位于3个国家超过400位工程师，固件部门已经多年on the critical path，已经尝试过多种方案。
08年时，提交代码到trunk需1周，每天1/2个build，全回归手工测试需6周
Re-architecture: 减少硬件变种，创建一个单一package，实现CI，投资于广泛的测试自动化，创建用于自动化的仿真器
Developer做Demo时即问，代码是否已经合并到了trunk？是否已经有自动化测试？ 
到2011年时，创新的时间由5%升级到40%。开发成本降低40%，同时开发的程序增长了140%，每个程序的开发成本降低了78%，创新的资源增加了8倍