持續交付

《持續交付(發佈可靠軟件的系統方法)》講述如何實現更快、更可靠、低成本的自動化軟件交付，描述瞭如何通過增加反饋，並改進開發人員、測試人員、運維人員和項目經理之間的協作來達到這個目標。《持續交付(發佈可靠軟件的系統方法)》由三部分組成。第一部分闡述了持續交付背後的一些原則，以及支持這些原則的實踐。第二部分是本書的核心，全面講述了部署流水線。第三部分圍繞部署流水線的投入產出討論了更多細節，包括增量開發技術、高級版本控制模式，以及基礎設施、環境和數據的管理和組織治理。 《持續交付(發佈可靠軟件的系統方法)》適合所有開發人員、測試人員、運維人員和項目經理學習參考。 ^[1] 

Jez Humble ToughtWorks公司首席諮詢顧問，致力於幫助企業快速、可靠地交付高質量軟件，經常在各種敏捷技術大會上發表演講，擁有牛津大學物理學學士學位和 倫敦大學民族音樂學的 碩士學位。曾在各行業和不同技術領域擔任系統管理員、開發人員、培訓人員、諮詢師和經理人員。 ^[1] 

David Farley 正在幫助構建倫敦多資產交易所（LMAE）。他具有20年的大型分佈式系統開發經驗，是採用敏捷開發技術的先行者，曾作為技術負責人蔘加了ThoughtWorks公司許多極具挑戰性的軟件項目。 ^[1] 

第一部分 基礎篇

第1 章 軟件交付的問題　 2

1.1 引言　2

1.2 一些常見的發佈反模式　 3

1.2.1 反模式：手工部署軟件　 4

1.2.2 反模式：開發完成之後才向類生產環境部署　 5

1.2.3 反模式：生產環境的手工配置管理　7

1.2.4 我們能做得更好嗎　 8

1.3 如何實現目標　 9

1.3.1 每次修改都應該觸發反饋流程　10

1.3.2 必須儘快接收反饋　 11

1.3.3 交付團隊必須接收反饋並作出反應　 12

1.3.4 這個流程可以推廣嗎　12

1.4 收效　12

1.4.1 授權團隊　13

1.4.2 減少錯誤　13

1.4.3 緩解壓力　15

1.4.4 部署的靈活性　16

1.4.5 多加練習，使其完美　17

1.5 候選發佈版本　17

1.6 軟件交付的原則　19

1.6.1 為軟件的發佈創建一個可重複且可靠的過程　19

1.6.2 將幾乎所有事情自動化　19

1.6.3 把所有的東西都納入版本控制　20

1.6.4 提前並頻繁地做讓你感到痛苦的事　20

1.6.5 內建質量　21

1.6.6 “DONE”意味着“已發佈” 　 21

1.6.7 交付過程是每個成員的責任　 22

1.6.8 持續改進　22

1.7 小結　 23

第2 章 配置管理　24

2.1 引言　24

2.2 使用版本控制　25

2.2.1 對所有內容進行版本控制　26

2.2.2 頻繁提交代碼到主幹　28

2.2.3 使用意義明顯的提交註釋　29

2.3 依賴管理　30

2.3.1 外部庫文件管理　30

2.3.2 組件管理　30

2.4 軟件配置管理　31

2.4.1 配置與靈活性　31

2.4.2 配置的分類　 33

2.4.3 應用程序的配置管理　33

2.4.4 跨應用的配置管理　36

2.4.5 管理配置信息的原則　 37

2.5 環境管理　 38

2.5.1 環境管理的工具　41

2.5.2 變更過程管理　41

2.6 小結　 42

第3 章 持續集成　43

3.1 引言　43

3.2 實現持續集成　44

3.2.1 準備工作　44

3.2.2 一個基本的持續集成系統　45

3.3 持續集成的前提條件　46

3.3.1 頻繁提交　46

3.3.2 創建全面的自動化測試套件　47

3.3.3 保持較短的構建和測試過程　47

3.3.4 管理開發工作區　 49

3.4 使用持續集成軟件　49

3.4.1 基本操作　 49

3.4.2 鈴聲和口哨　 50

3.5 必不可少的實踐　 52

3.5.1 構建失敗之後不要提交新代碼　52

3.5.2 提交前在本地運行所有的提交測試，或者讓持續集成服務器完成此事　53

3.5.3 等提交測試通過後再繼續工作　54

3.5.4 回家之前，構建必須處於成功狀態　 54

3.5.5 時刻準備着回滾到前一個版本　55

3.5.6 在回滾之前要規定一個修復時間　56

3.5.7 不要將失敗的測試註釋掉　 56

3.5.8 為自己導致的問題負責　56

3.5.9 測試驅動的開發　57

3.6 推薦的實踐　 57

3.6.1 極限編程開發實踐　57

3.6.2 若違背架構原則，就讓構建失敗　 58

3.6.3 若測試運行變慢，就讓構建失敗　 58

3.6.4 若有編譯警告或代碼風格問題，就讓測試失敗　59

3.7 分佈式團隊　60

3.7.1 對流程的影響　60

3.7.2 集中式持續集成　 61

3.7.3 技術問題　61

3.7.4 替代方法　 62

3.8 分佈式版本控制系統　63

3.9 小結　66

第4 章 測試策略的實現　 67

4.1 引言　 67

4.2 測試的分類　 68

4.2.1 業務導向且支持開發過程的測試　69

4.2.2 技術導向且支持開發過程的測試　72

4.2.3 業務導向且評價項目的測試　72

4.2.4 技術導向且評價項目的測試　73

4.2.5 測試替身　74

4.3 現實中的情況與應對策略　75

4.3.1 新項目　75

4.3.2 項目進行中　 76

4.3.3 遺留系統　 77

4.3.4 集成測試　78

4.4 流程　80

4.5 小結　82

第二部分 部署流水線

第5 章 部署流水線解析　84

5.1 引言　 84

5.2 什麼是部署流水線　85

5.3 部署流水線的相關實踐　91

5.3.1 只生成一次二進制包　 91

5.3.2 對不同環境採用同一部署方式　93

5.3.3 對部署進行冒煙測試　 94

5.3.4 向生產環境的副本中部署　94

5.3.5 每次變更都要立即在流水線中傳遞　 95

5.3.6 只要有環節失敗，就停止整個流水線　96

5.4 提交階段　96

5.5 自動化驗收測試之門　99

5.6 後續的測試階段　102

5.6.1 手工測試　 103

5.6.2 非功能測試　103

5.7 發佈準備　104

5.7.1 自動部署與發佈　 104

5.7.2 變更的撤銷　106

5.7.3 在成功的基礎上構建　 107

5.8 實現一個部署流水線　 107

5.8.1 對價值流進行建模並創建簡單的可工作框架　 107

5.8.2 構建和部署過程的自動化　108

5.8.3 自動化單元測試和代碼分析　109

5.8.4 自動化驗收測試　 109

5.8.5 部署流水線的演進　 110

5.9 度量　111

5.10 小結　113 ^[1] 

第6 章 構建與部署的腳本化　 115

6.1 引言　115

6.2 構建工具概覽　116

6.2.1 Make　118

6.2.2 Ant　118

6.2.3 NAnt 與 MSBuild　119

6.2.4 Maven　120

6.2.5 Rake 　121

6.2.6 Buildr 　121

6.2.7 Psake 　121

6.3 構建部署腳本化的原則與實踐　 122

6.3.1 為部署流水線的每個階段創建腳本　122

6.3.2 使用恰當的技術部署應用程序　 122

6.3.3 使用同樣的腳本向所有環境部署　123

6.3.4 使用操作系統自帶的包管理工具　124

6.3.5 確保部署流程是冪等的（Idempotent）　125

6.3.6 部署系統的增量式演進　126

6.4 面向JVM 的應用程序的項目結構　126

6.5 部署腳本化　129

6.5.1 多層的部署和測試　130

6.5.2 測試環境配置　131

6.6 小貼士　132

6.6.1 總是使用相對路徑　132

6.6.2 消除手工步驟　132

6.6.3 從二進制包到版本控制庫的內建可追溯性　133

6.6.4 不要把二進制包作為構建的一部分放到版本控制庫中　133

6.6.5 “test”不應該讓構建失敗　134

6.6.6 用集成冒煙測試來限制應用程序　134

6.6.7 .NET 小貼士　135

6.7 小結　135

第7 章 提交階段　137

7.1 引言　137

7.2 提交階段的原則和實踐　138

7.2.1 提供快速有用的反饋　138

7.2.2 何時令提交階段失敗　139

7.2.3 精心對待提交階段　140

7.2.4 讓開發人員也擁有所有權　140

7.2.5 在超大項目團隊中指定一個構建負責人　141

7.3 提交階段的結果　141

7.4 提交測試套件的原則與實踐　144

7.4.1 避免用户界面　145

7.4.2 使用依賴注入　145

7.4.3 避免使用數據庫　145

7.4.4 在單元測試中避免異步　146

7.4.5 使用測試替身　 146

7.4.6 最少化測試中的狀態　 149

7.4.7 時間的偽裝　150

7.4.8 蠻力　150

7.5 小結　 151

第8 章 自動化驗收測試　152

8.1 引言　 152

8.2 為什麼驗收測試是至關重要的　 153

8.2.1 如何創建可維護的驗收測試套件　155

8.2.2 GUI 上的測試　 156

8.3 創建驗收測試　157

8.3.1 分析人員和測試人員的角色　157

8.3.2 迭代開發項目中的分析工作　157

8.3.3 將驗收條件變成可執行的規格説明書　 158

8.4 應用程序驅動層　161

8.4.1 如何表述驗收條件　 163

8.4.2 窗口驅動器模式：讓測試與GUI 解耦　164

8.5 實現驗收測試　166

8.5.1 驗收測試中的狀態　 166

8.5.2 過程邊界、封裝和測試　 168

8.5.3 管理異步與超時問題　 169

8.5.4 使用測試替身對象　 171

8.6 驗收測試階段　174

8.6.1 確保驗收測試一直處於通過狀態　175

8.6.2 部署測試　177

8.7 驗收測試的性能　178

8.7.1 重構通用任務　 178

8.7.2 共享昂貴資源　 179

8.7.3 並行測試　180

8.7.4 使用計算網格　 180

8.8 小結　181

第9 章 非功能需求的測試　183

9.1 引言　183

9.2 非功能需求的管理　184

9.3 如何為容量編程　186

9.4 容量度量　188

9.5 容量測試環境　191

9.6 自動化容量測試　194

9.6.1 通過UI 的容量測試　195

9.6.2 基於服務或公共API 來錄製交互操作　196

9.6.3 使用錄製的交互模板　 197

9.6.4 使用容量測試樁開發測試　198

9.7 將容量測試加入到部署流水線中　199

9.8 容量測試系統的附加價值　 201

9.9 小結　 202

第10 章 應用程序的部署與發佈　 203

10.1 引言　203

10.2 創建發佈策略　 204

10.2.1 發佈計劃　205

10.2.2 發佈產品　205

10.3 應用程序的部署和晉級　 206

10.3.1 首次部署　206

10.3.2 對發佈過程進行建模並讓構建晉級　 207

10.3.3 配置的晉級　209

10.3.4 聯合環境　209

10.3.5 部署到試運行環境　 210

10.4 部署回滾和零停機發布　211

10.4.1 通過重新部署原有的正常版本來進行回滾　211

10.4.2 零停機發布　212

10.4.3 藍綠部署　 212

10.4.4 金絲雀發佈　213

10.5 緊急修復　216

10.6 持續部署　216

10.7 小貼士和竅門　 219

10.7.1 真正執行部署操作的人應該參與部署過程的創建　219

10.7.2 記錄部署活動　 220

10.7.3 不要刪除舊文件，而是移動到別的位置　 220

10.7.4 部署是整個團隊的責任　 220

10.7.5 服務器應用程序不應該有GUI 　220

10.7.6 為新部署留預熱期　 221

10.7.7 快速失敗　 221

10.7.8 不要直接對生產環境進行修改　222

10.8 小結　222

第三部分 交付生態圈

第11 章 基礎設施和環境管理　 224

11.1 引言　 224

11.2 理解運維團隊的需要　 225

11.2.1 文檔與審計　 226

11.2.2 異常事件的告警　 227

11.2.3 保障IT 服務持續性的計劃　227

11.2.4 使用運維團隊熟悉的技術　 228

11.3 基礎設施的建模和管理　229

11.3.1 基礎設施的訪問控制　 230

11.3.2 對基礎設施進行修改　 231

11.4 服務器的準備及其配置的管理　 232

11.4.1 服務器的準備　 233

11.4.2 服務器的持續管理　 234

11.5 中間件的配置管理　239

11.5.1 管理配置項　 239

11.5.2 產品研究　 241

11.5.3 考查中間件是如何處理狀態的　 242

11.5.4 查找用於配置的API 　 242

11.5.5 使用更好的技術　 243

11.6 基礎設施服務的管理　243

11.7 虛擬化　245

11.7.1 虛擬環境的管理　 247

11.7.2 虛擬環境和部署流水線　249

11.7.3 用虛擬環境做高度的並行測試　251

11.8 雲計算　252

11.8.1 雲中基礎設施　253

11.8.2 雲中平台　254

11.8.3 沒有普適存在　255

11.8.4 對雲計算的批評　256

11.9 基礎設施和應用程序的監控　256

11.9.1 收集數據　257

11.9.2 記錄日誌　259

11.9.3 建立信息展示板　259

11.9.4 行為驅動的監控　261

11.10 小結　261

第12 章 數據管理　263

12.1 引言　263

12.2 數據庫腳本化　264

12.3 增量式修改　265

12.3.1 對數據庫進行版本控制　265

12.3.2 聯合環境中的變更管理　267

12.4 數據庫回滾和無停機發布　268

12.4.1 保留數據的回滾　268

12.4.2 將應用程序部署與數據庫遷移解耦　269

12.5 測試數據的管理　270

12.5.1 為單元測試進行數據庫模擬　271

12.5.2 管理測試與數據之間的耦合　272

12.5.3 測試獨立性　272

12.5.4 建立和銷燬　273

12.5.5 連貫的測試場景　273

12.6 數據管理和部署流水線　274

12.6.1 提交階段的測試數據　274

12.6.2 驗收測試中的數據　275

12.6.3 容量測試的數據　276

12.6.4 其他測試階段的數據　277

12.7 小結　278

第13 章 組件和依賴管理　280

13.1 引言　280

13.2 保持應用程序可發佈　281

13.2.1 將新功能隱蔽起來，直到它完成為止　282

13.2.2 所有修改都是增量式的　 283

13.2.3 通過抽象來模擬分支　 284

13.3 依賴　285

13.3.1 依賴地獄　 286

13.3.2 庫管理　 287

13.4 組件　289

13.4.1 如何將代碼庫分成多個組件　289

13.4.2 將組件流水線化　 292

13.4.3 集成流水線　 293

13.5 管理依賴關係圖　295

13.5.1 構建依賴圖　 295

13.5.2 為依賴圖建立流水線　 297

13.5.3 什麼時候要觸發構建　 299

13.5.4 謹慎樂觀主義　 300

13.5.5 循環依賴　302

13.6 管理二進制包　303

13.6.1 製品庫是如何運作的　 303

13.6.2 部署流水線如何與製品庫相結合　 304

13.7 用Maven 管理依賴　304

13.8 小結　 308

第14 章 版本控制進階　 309

14.1 引言　309

14.2 版本控制的歷史　310

14.2.1 CVS 　310

14.2.2 SVN 　311

14.2.3 商業版本控制系統　 312

14.2.4 放棄悲觀鎖　 313

14.3 分支與合併　 314

14.3.1 合併　 316

14.3.2 分支、流和持續集成　 317

14.4 DVCS 　319

14.4.1 什麼是DVCS 　 319

14.4.2 DVCS 簡史　 321

14.4.3 企業環境中的DVCS　 321

14.4.4 使用DVCS　 322

14.5 基於流的版本控制系統　 324

14.5.1 什麼是基於流的版本控制系統　324

14.5.2 使用流的開發模型　 326

14.5.3 靜態視圖和動態視圖　 327

14.5.4 使用基於流的版本控制系統做持續集成　 328

14.6 主幹開發　329

14.7 按發佈創建分支　332

14.8 按功能特性分支　333

14.9 按團隊分支　335

14.10 小結　338

第15 章 持續交付管理　340

15.1 引言　 340

15.2 配置與發佈管理成熟度模型　341

15.3 項目生命週期　 343

15.3.1 識別階段　344

15.3.2 啓動階段　345

15.3.3 初始階段　346

15.3.4 開發與發佈　347

15.3.5 運營階段　 349

15.4 風險管理流程　 350

15.4.1 風險管理基礎篇　 350

15.4.2 風險管理時間軸　 351

15.4.3 如何做風險管理的練習　352

15.5 常見的交付問題、症狀和原因　353

15.5.1 不頻繁的或充滿缺陷的部署　353

15.5.2 較差的應用程序質量　 354

15.5.3 缺乏管理的持續集成工作流程　355

15.5.4 較差的配置管理　 355

15.6 符合度與審計　356

15.6.1 文檔自動化　356

15.6.2 加強可跟蹤性　 357

15.6.3 在筒倉中工作　 358

15.6.4 變更管理　358

15.7 小結　360

參考書目　361 ^[1]