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倍