1. 引言
本書的核心模式是部署流水線，以持續集成理論作為其理論基石
部署流水線有三個目標
- 讓軟件構建，部署，測試和發布過程對所有人可見，促進合作
- 改善反饋，能在整個過程中更早的發現和解決問題（做一件事，有問題發生是一定的，重要的是快速的定位和解決問題）
- 使在任何環境下部署和發布任意版本的應用成為自動化的過程，提高效率
一個簡單的部署流水線
提交階段 ==> 自動化驗收測試 ==> 自動化容量測試 ==> 手工測試 ==> 發布
2. 一些常見的反模式
2.1. 反模式：手工部署軟件
這個反模式一般具有如下特征
- 有一份詳盡的操作文檔，其中描述了多出需要注意的地方（呵呵，很多地方連操作文檔都沒有啊）
- 手工測試程序是否運行正確（懶，一不定會測，累，漏測了。。。）
- 總有客戶來問，部署怎么又出問題了（金主生氣，就問你緊不緊張）
- 如果是集群環境，個環境配置經常有出入（線上訪問測試庫）
- 發布過程時間較長（人的速度哪能跟計算機比啊）
- 發布結果無法預測（憑運氣）
- 經常加班，還搞不定問題（惡性循環）
理想的部署流程應該是
- 挑選要部署的版本和環境
- 按一下“部署”按鈕
為什么需要部署自動化
- 使部署過程可重復
- 免去部署文檔的維護，一個部署腳本即是所有文檔
- 部署過程可審計追蹤，我有日志，別抵賴，呔，哪里跑
- 擺脫對人的過分依賴，讓傻子也能上線
2.2. 反模式：開發完成之后才向生產環境部署
經常出現的情況
- 運維人員之前一直沒有接觸過應用程序，莫名其妙扔過來一個包，老子知道你是干嘛滴啊
- 程序相關的配置，數據庫腳本，部署文檔等都沒有在正式環境下測試過（膽子真大）
- 開發團隊和運維團隊協作太少（除了互相甩鍋沒啥交流）
導致的各種問題
- 第一次部署成了噩夢（無準備之仗不好打啊）
- 開發環境和部署環境差距越大，問題越多（絕大部分問題都是不一致導致的）
- 各團隊之間協作焦頭爛額（可參照正規軍與烏合之眾的區別）
解決方案
將測試，部署和發布活動都納入到開發過程中，讓他們成為正常開發流程的一部分，對部署過程也進行測試（可以把部署當成一個產品來開發）
2.3. 反模式：生產環境的手工配置
這種反模式經常有如下特征
- 誒，我本地好使啊（呵呵）
- 集群中各節點表現不同（配置參數丟三落四）
- 每次準備環境時間長（上廁所，到咖啡）
- 無法回滾（要是真回滾了，估計產生更多問題）
- 不知不覺，集群中的服務器，操作系統配置變得都不一樣了（人的腦子啊，是相當不靠譜的）
怎樣解決這些問題？
采用配置管理，可以重復的創建開發應用程序所需要的每個基礎設施
對于各個環境中的信息，都應該完全掌控，而且，所有環境的生成，配置的修改都應該由自動化程序實現，禁止手動修改（手動是萬惡之源）
2.4. 如何改變這種情況
采用部署流水線，將軟件的發布變成一種低風險、頻繁、廉價、迅速且可預見的過程
最后的目標是實現將自動化的測試和部署，以及全面的配置管理結合在一起，實現一鍵式軟件發布
3. 如何實現目標
為保證能持續的以高質量交付我們的軟件，需要頻繁的自動化發布軟件
對于頻繁的自動化發布軟件，反饋是至關重要的，對于反饋，應該達到三個標準
- 無論什么樣的修改都應該觸發反饋流程（就像神經系統一樣，時刻監控人的動態）
- 反饋應該盡快發出（被開水燙了，馬上知道疼）
- 交付團隊必須接收反饋，并依據它做出行動響應（疼了你得躲啊。。。）
下面詳細介紹一下這三個標準
3.1. 無論什么樣的修改都應該觸發反饋流程
這些修改包括對以下項的修改
反饋流程
完全自動化的方式盡可能的測試每一次變更
測試內容包括但不限于
- 創建可執行代碼的流程必須是能奏效的。這用于驗證源代碼是否符合語法
- 軟件的單元測試必須是成功的。這可以檢查應用程序的行為是否與期望相同
- 軟件應該滿足一定的質量標準，比如測試覆蓋率以及其他與技術相關的度量項
- 軟件的功能驗收測試必須是成功的。這可以檢查應用是否滿足業務驗收條件，交付了所期望的業務價值
- 軟件的非功能測試必須是成功的。這可以檢查應用程序是否滿足用戶對性能、有效性、安全性等方面的要求
- 軟件必須通過了探索性測試，并給客戶以及部分用戶做過演示。這些通常在一個手工測試環境上完成。此時，產品負責人可能認為軟件功能還有缺失，我們自己也可能發現需要修復的缺陷，還要為其寫自動化測試來避免回歸測試
3.2. 反饋應該盡快發出
關鍵是自動化，主要通過部署流水線來實現，后面各章會詳細介紹
3.3. 交付團隊必須接收反饋，并依據它做出行動響應
沒有響應，反饋何用？
3.4. 這個流程可以推廣嗎
很多思想來源于精益制造，目標是快速交付高質量的產品，聚焦于消除浪費，減少成本
4. 收效
4.1. 授權團隊
讓整個團隊合作在一起
4.2. 較少錯誤
通過減少手工的重復任務，避免大部分錯誤
4.3. 緩解壓力
讓發布任務變得簡單可控，免得每次發布都如臨大敵
4.4. 部署的靈活性
隨時找到以往的部署版本，意見部署任意版本
4.5. 多加練習，使其完美
目標是不管部署到什么環境，都使用相同的部署方法
5. 候選發布版本
每次提交代碼都產生一個可發布版本
但是實際開發中，要想驗證一個可發布版本，就要進行一次集成，通常這個過程難以控制，所以就會推遲，集成頻率越低，越痛苦，但是越痛苦的事，越要頻繁去做，要么會更痛苦
本書會通過持續集成這一實踐來讓集成變得無痛
6. 軟件交付的原則
為了保證高質量的持續交付，下面的可以當做行為準則了
6.1. 為軟件的發布創建一個可重復且可靠的過程
歸根結底，軟件的部署包括三件事
- 提供并管理軟件所需要的運行環境，包括硬件配置，所依賴的軟件，基礎設施以及所需的外部服務
- 將應用程序的正確版本安裝其上
- 配置應用程序，包括所需的任何數據和狀態
6.2. 將幾乎所有的事情自動化
能讓機器去做的就別自己做了
6.3. 把所有的東西都納入版本控制
使每個版本相關的信息都能很快找到
6.4. 提前并頻繁的做讓你感到痛苦的事
這是一條很有用的啟發式原則，更多解釋可以看看《少有人走的路》
6.5. 內建質量
每個人都對質量負責，有問題立馬解決
6.6. “DONE”意味著“已發布”
我們認為一個特性只有交到用戶手中才算DONE，而不是開發完了就OK了
6.7. 交付過程是每個成員的責任
從相互指責扯皮到共同協作
6.8. 持續改進
戴明環（plan->do->check->act）
7. 小結
本書的目標是讓發布過程變得無痛
新開了公眾號，歡迎關注，主要分享一些讀書筆記
