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倍
