小威廉·詹姆斯·亞當斯，藝名威廉，是一名美國饒舌歌手、歌手、詞曲作家、音樂製作人及演員。美國嘻哈音樂團體黑眼豆豆的創辦者之一，也是該團體現任成員。
維基百科
請讓你的代碼庫隨時保持可發佈狀態。持續交付流水線可以實現自動化版本控制、自動測試和自動部署，將開發人員的干預降至最低。掌握持續交付的工具和實踐，你將能夠快速且一致地添加功能和推送更新。
《持續交付圖解》是建立和使用持續交付流水線的友好指南。每一章都介紹了在設置CD系統時將面臨的不同場景，包括自動擴展和測試遺留應用程式等現實問題的示例。作者Christie Wilson採用與具體工具無關的方法，通過插圖、清晰的解釋和實踐練習來指導你的每一步學習。
| FindBook |
|
有 1 項符合
克里斯蒂·威爾遜的圖書 |
 |
$ 606 | 持續交付圖解
作者：（美）克里斯蒂·威爾遜 ／ 譯者：姚冬 出版社：清華大學出版社 出版日期：2025-03-01 語言：簡體中文 規格：平裝 / 378頁 / 19 x 26 x 1.89 cm / 普通級/ 1-1  博客來 - 程式設計
- 來源網頁  看圖書介紹
|
|
|
威爾
圖書介紹 - 資料來源：博客來 評分：
圖書名稱：持續交付圖解
內容簡介
作者介紹
Christie Wilson是一名軟體工程師。她經常在Kubecon、OSCON、QCon、PyCon等會議上就CI/CD及相關主題發表演講。Christie的職業生涯始於移動端Web應用開發。在從事AAA遊戲的後端開發時，她編寫的功能通常在系統大規模發佈後才會被許多人同時使用。為此，她構建了負載和系統測試平臺。
憑藉處理複雜部署環境、核心關鍵系統和應對突發流量的經驗，她加入了Google並從事相關方向的工作。在Google，她為AppEngine、boot-strapped Knative構建了內部生產力工具，並創建了Tekton，這是一個基於Kubernetes(目前有65家以上的公司參與)構建的雲原生CI/CD平臺。
憑藉處理複雜部署環境、核心關鍵系統和應對突發流量的經驗，她加入了Google並從事相關方向的工作。在Google，她為AppEngine、boot-strapped Knative構建了內部生產力工具，並創建了Tekton，這是一個基於Kubernetes(目前有65家以上的公司參與)構建的雲原生CI/CD平臺。
目錄
第Ⅰ部分 持續交付入門1
第1章 歡迎閱讀本書3
1.1 你需要持續交付嗎4
1.2 為什麼要持續交付5
1.3 持續交付7
1.4 集成8
1.5 持續集成9
1.6 我們能交付什麼10
1.7 交付11
1.8 持續交付/持續部署12
1.9 持續交付的要素13
1.10 結論14
1.11 本章小結14
1.12 接下來……14
第2章 基礎流水線15
2.1 貓咪圖片網站16
2.2 貓咪圖片網站源碼17
2.3 貓咪圖片網站流水線18
2.4 什麼是流水線，什麼是任務19
2.5 CD流水線中的基礎任務20
2.6 門禁與轉換21
2.7 CD：門禁機制與轉換22
2.8 貓咪圖片網站服務流水線23
2.9 運行流水線24
2.10 每天都運行一次25
2.11 嘗試持續集成26
2.12 使用通知27
2.13 拓展手動工作28
2.14 通過webhook自動化29
2.15 拓展webhook30
2.16 在流水線出現問題時不要提交代碼變更31
2.17 貓咪圖片網站的CD32
2.18 名稱中的學問33
2.19 結論34
2.20 本章小結34
2.21 接下來……34
第Ⅱ部分 讓軟體一直保持在可交付狀態35
第3章 版本控制是發佈軟體的唯一方式37
3.1 Sasha和Sarah的創業38
3.2 所有類型的資料39
3.3 源碼與軟體40
3.4 代碼庫和版本41
3.5 持續交付和版本控制42
3.6 Git和GitHub43
3.7 第一次代碼提交——出錯啦44
3.8 主分支出錯45
3.9 推送與拉取46
3.10 我們在進行持續交付嗎48
3.11 讓版本控制系統保持可發佈狀態49
3.12 代碼變更提交到版本控制系統時的觸發器50
3.13 觸發使用者服務流水線51
3.14 構建使用者服務52
3.15 雲端的使用者服務53
3.16 連接RandomCloud資料庫54
3.17 管理使用者服務55
3.18 使用者服務宕機56
3.19 被自動化打敗57
3.20 什麼是可信代碼源58
3.21 使用者服務的配置即代碼60
3.22 配置Deployaker62
3.23 配置即代碼63
3.24 發佈軟體與配置變更64
3.25 結論66
3.26 本章小結66
3.27 接下來……66
第4章 有效使用靜態代碼檢查67
4.1 Becky和超級遊戲控制台68
4.2 採用靜態代碼檢查解決問題69
4.3 關於靜態代碼檢查的內幕70
4.4 Pylint的故事和很多問題71
4.5 遺留代碼：使用系統化方法72
4.6 第1步：根據編碼規範進行配置73
4.7 第2步：建立基線74
4.8 第3步：在提交時強制執行75
4.9 向流水線添加強制執行76
4.10 第4步：分而治之77
4.11 隔離：不是所有問題都應該修復78
4.12 強制隔離79
4.13 並非所有問題都同等重要80
4.14 靜態代碼檢查問題的類型81
4.15 缺陷優先，風格其後82
4.16 克服重重障礙83
4.17 結論85
4.18 本章小結85
4.19 接下來……85
第5章 處理有雜訊的測試87
5.1 持續交付和測試88
5.2 “全民霜淇淋”停機事件89
5.3 信號與雜訊90
5.4 雜訊的成功91
5.5 失敗是如何變成雜訊的92
5.6 從雜訊到信號94
5.7 讓測試通過(變綠)95
5.8 又一次停機96
5.9 通過測試仍然可能會有雜訊97
5.10 修復測試失敗98
5.11 失敗的方式：脆弱的測試99
5.12 對失敗做出反應100
5.13 修復測試：修改代碼或測試101
5.14 重試的危險102
5.15 重試重新訪問103
5.16 為什麼要重試105
5.17 變綠並保持綠色106
5.18 結論108
5.19 本章小結108
5.20 接下來……108
第6章 讓那些緩慢的測試套件變得更快109
6.1 狗狗圖片網站110
6.2 當流水線過於簡單時111
6.3 新工程師試圖提交代碼112
6.4 測試和持續交付113
6.5 診斷：速度太慢114
6.6 測試金字塔115
6.7 先運行執行快的測試用例116
6.8 兩條流水線117
6.9 獲得正確的平衡118
6.10 改變金字塔比例119
6.11 安全地調整測試用例120
6.12 測試覆蓋率121
6.13 強制要求測試覆蓋率122
6.14 流水線中的測試覆蓋率123
6.15 在具備覆蓋率的金字塔中移動測試用例124
6.16 沿著金字塔往下移動什麼125
6.17 遺留的測試用例和FUD127
6.18 並行運行測試用例128
6.19 何時可以並行運行測試用例129
6.20 更新流水線130
6.21 還是太慢了131
6.22 分片測試，又稱並行 132
6.23 如何分片133
6.24 更複雜的分片134
6.25 分片流水線135
6.26 對流覽器測試套件進行分片136
6.27 流水線中的分片137
6.28 狗狗圖片網站的流水線138
6.29 結論142
6.30 本章小結142
6.31 接下來……142
第7章 在正確的時間發出正確的信號143
7.1 CoinExCompare網站144
7.2 代碼變更的生命週期145
7.3 僅在代碼合併前進行的CI146
7.4 代碼變更出錯的時間線147
7.5 僅在合併前運行的CI未命中缺陷148
7.6 兩張圖的故事：默認為7天149
7.7 兩張圖的故事：默認為30天150
7.8 衝突並不是總會被發現151
7.9 單元測試呢152
7.10 PR觸發器仍然會讓缺陷潛入153
7.11 合併前以及合併後的CI154
7.12 選項1：定期運行CI155
7.13 選項1：設置定期運行的CI156
7.14 選項2：要求特性分支是最新的157
7.15 選項2：成本是多少158
7.16 選項3：自動合併CI159
7.17 選項3：使用最新的主分支運行CI160
7.18 選項3：合併事件161
7.19 選項3：合併佇列162
7.20 選項3：CoinExCompare網站的合併佇列163
7.21 哪裡還會發生錯誤165
7.22 測試脆弱性和PR觸發的CI166
7.23 通過定期測試捕獲脆弱的測試167
7.24 缺陷和構建168
7.25 CI與構建和部署169
7.26 使用相同的邏輯構建和部署170
7.27 通過構建改進CI流水線171
7.28 重新審視代碼變更時間表172
7.29 結論174
7.30 本章小結174
7.31 接下來……174
第Ⅲ部分 讓交付變得簡單175
第8章 輕鬆交付從版本控制出發177
8.1 回到Watch Me Watch專案178
8.2 DORA指標179
8.3 如果我不運行服務呢181
8.4 Watch Me Watch 與精英效能團隊183
8.5 給Watch Me Watch提升速率184
8.6 與AllCatsAllTheTime集成 185
8.7 主幹開發186
8.8 特性增量式交付187
8.9 跳過測試的提交188
8.10 代碼評審和“不完整”的代碼189
8.11 保持這個勢頭191
8.12 提交不完整的代碼192
8.13 評審進行中的代碼193
8.14 與此同時，讓我們回到端到端測試194
8.15 可見的好處195
8.16 不斷縮短的變更前置時間197
8.17 繼續AllCatsAllTheTime開發198
8.18 部署視窗和代碼凍結199
8.19 速率提高200
8.20 結論201
8.21 本章小結201
8.22 接下來……201
第9章 安全可靠的構建203
9.1 Top Dog Maps204
9.2 當構建流程僅僅記錄在文檔中時205
9.3 安全和可靠構建的屬性206
9.4 始終可發佈208
9.5 自動化構建209
9.6 構建即代碼210
9.7 使用CD服務211
9.8 臨時構建環境212
9.9 Miguel的計畫213
9.10 從純文檔到擁有版本控制的腳本 214
9.11 自動化容器化構建215
9.12 安全和可靠的構建流程217
9.13 介面的變更和導致的缺陷219
9.14 當構建產生缺陷時220
9.15 構建與溝通221
9.16 語義化版本控制222
9.17 版本控制的重要性223
9.18 又一次故障！225
9.19 構建時依賴導致的錯誤226
9.20 鎖定依賴項版本227
9.21 僅僅鎖定版本還不足夠228
9.22 鎖定雜湊值229
9.23 結論231
9.24 本章小結231
9.25 接下來……231
第10章 可信賴的部署233
10.1 部署困擾不斷234
10.2 DORA的穩定性指標235
10.3 Plenty of Woofs的DORA指標237
10.4 減少部署頻率嗎238
10.5 增加部署頻率嗎239
10.6 每日部署與故障240
10.7 增加部署頻率的步驟241
10.8 修復流程中的問題242
10.9 滾動更新243
10.10 通過滾動更新修復缺陷244
10.11 回滾245
10.12 回滾策略 = 即時改善246
10.13 回滾策略實戰248
10.14 藍綠部署249
10.15 使用藍綠部署加速故障恢復時間250
10.16 金絲雀發佈更快且更穩定251
10.17 金絲雀部署的前提條件252
10.18 金絲雀發佈的基線254
10.19 金絲雀發佈的服務恢復時間255
10.20 增加部署頻率257
10.21 每日金絲雀發佈策略下的DORA指標258
10.22 持續部署259
10.23 使用持續部署的時機260
10.24 強制性的QA階段261
10.25 QA與持續部署262
10.26 精英效能團隊264
10.27 結論265
10.28 本章小結265
10.29 接下來……265
第Ⅳ部分 設計持續交付267
第11章 啟動包：從零到CD269
11.1 啟動包：概覽270
11.2 回顧：通用的CD流水線任務271
11.3 典型的發佈流水線272
11.4 典型的CI流水線273
11.5 兩條都帶觸發器的流水線274
11.6 綠地項目：邁向CD276
11.7 Gulpy277
11.8 綠地項目：從零到CD278
11.9 第一步：它能構建嗎279
11.10 選擇CD系統280
11.11 建立初始的自動化281
11.12 代碼的狀態：靜態代碼檢查282
11.13 代碼的狀態：單元測試283
11.14 代碼的狀態：覆蓋率284
11.15 超越CI：發佈285
11.16 部署286
11.17 擴展測試287
11.18 集成測試和端到端測試的任務288
11.19 完成CI流水線289
11.20 Gulpy完整的流水線290
11.21 遺留項目：邁向CD291
11.22 Rebellious Hamster292
11.23 第一步：確定增量目標的優先順序293
11.24 首先關注痛點294
11.25 Rebellious Hamster的痛點295
11.26 知道何時出現了問題296
11.27 隔離並添加測試297
11.28 具有更多測試的遺留項目流水線298
11.29 使部署更加自動化299
11.30 創建發佈流水線300
11.31 Rebellious Hamster的發佈流水線301
11.32 Rebellious Hamster的完整流水線302
11.33 結論303
11.34 本章小結303
11.35 接下來……303
第12章 腳本也是代碼305
12.1 Purrfect Bank306
12.2 CD的問題307
12.3 Purrfect Bank的CD概覽308
12.4 支付組織的Bash腳本庫309
12.5 交易服務流水線310
12.6 從一個大腳本演化311
12.7 設計良好任務的原則312
12.8 打破巨型任務313
12.9 更新後的交易服務流水線314
12.10 調試Bash庫315
12.11 調查Bash庫的缺陷316
12.12 為什麼會引入這個缺陷317
12.13 Bash的作用318
12.14 何時Bash不太好319
12.15 shell腳本與通用語言321
12.16 從shell腳本到通用程式設計語言322
12.17 遷移計畫323
12.18 從Bash庫到擁有Bash的任務324
12.19 任務內的可重用Bash325
12.20 從Bash到Python326
12.21 任務即代碼327
12.22 CD腳本也是代碼328
12.23 結論329
12.24 本章小結329
12.25 接下來……329
第13章 流水線設計331
13.1 PetMatch332
13.2 匹配服務CD流水線333
13.3 CD流水線問題334
13.4 端到端測試流水線335
13.5 端到端測試流水線和錯誤336
13.6 最終行為337
13.7 圖形化最終部分338
13.8 匹配服務流水線中的最終行為339
13.9 端到端測試流水線和速度340
13.10 並存執行任務341
13.11 端到端測試流水線和測試速度342
13.12 並存執行和測試分片343
13.13 帶有分片的端到端測試流水線344
13.14 端到端測試流水線和信號345
13.15 單一CI流水線346
13.16 發佈流水線與信號347
13.17 CI流水線的差異348
13.18 合併流水線349
13.19 發佈流水線350
13.20 發佈流水線中的硬編碼351
13.21 通過參數化複用流水線352
13.22 使用可重用的流水線353
13.23 更新後的流水線354
13.24 解決PetMatch的CD問題355
13.25 期待的CD功能356
13.26 結論357
13.27 本章小結357
13.28 接下來……357
附錄359
附錄A -- CD系統361
附錄B -- 版本控制系統371
第1章 歡迎閱讀本書3
1.1 你需要持續交付嗎4
1.2 為什麼要持續交付5
1.3 持續交付7
1.4 集成8
1.5 持續集成9
1.6 我們能交付什麼10
1.7 交付11
1.8 持續交付/持續部署12
1.9 持續交付的要素13
1.10 結論14
1.11 本章小結14
1.12 接下來……14
第2章 基礎流水線15
2.1 貓咪圖片網站16
2.2 貓咪圖片網站源碼17
2.3 貓咪圖片網站流水線18
2.4 什麼是流水線，什麼是任務19
2.5 CD流水線中的基礎任務20
2.6 門禁與轉換21
2.7 CD：門禁機制與轉換22
2.8 貓咪圖片網站服務流水線23
2.9 運行流水線24
2.10 每天都運行一次25
2.11 嘗試持續集成26
2.12 使用通知27
2.13 拓展手動工作28
2.14 通過webhook自動化29
2.15 拓展webhook30
2.16 在流水線出現問題時不要提交代碼變更31
2.17 貓咪圖片網站的CD32
2.18 名稱中的學問33
2.19 結論34
2.20 本章小結34
2.21 接下來……34
第Ⅱ部分 讓軟體一直保持在可交付狀態35
第3章 版本控制是發佈軟體的唯一方式37
3.1 Sasha和Sarah的創業38
3.2 所有類型的資料39
3.3 源碼與軟體40
3.4 代碼庫和版本41
3.5 持續交付和版本控制42
3.6 Git和GitHub43
3.7 第一次代碼提交——出錯啦44
3.8 主分支出錯45
3.9 推送與拉取46
3.10 我們在進行持續交付嗎48
3.11 讓版本控制系統保持可發佈狀態49
3.12 代碼變更提交到版本控制系統時的觸發器50
3.13 觸發使用者服務流水線51
3.14 構建使用者服務52
3.15 雲端的使用者服務53
3.16 連接RandomCloud資料庫54
3.17 管理使用者服務55
3.18 使用者服務宕機56
3.19 被自動化打敗57
3.20 什麼是可信代碼源58
3.21 使用者服務的配置即代碼60
3.22 配置Deployaker62
3.23 配置即代碼63
3.24 發佈軟體與配置變更64
3.25 結論66
3.26 本章小結66
3.27 接下來……66
第4章 有效使用靜態代碼檢查67
4.1 Becky和超級遊戲控制台68
4.2 採用靜態代碼檢查解決問題69
4.3 關於靜態代碼檢查的內幕70
4.4 Pylint的故事和很多問題71
4.5 遺留代碼：使用系統化方法72
4.6 第1步：根據編碼規範進行配置73
4.7 第2步：建立基線74
4.8 第3步：在提交時強制執行75
4.9 向流水線添加強制執行76
4.10 第4步：分而治之77
4.11 隔離：不是所有問題都應該修復78
4.12 強制隔離79
4.13 並非所有問題都同等重要80
4.14 靜態代碼檢查問題的類型81
4.15 缺陷優先，風格其後82
4.16 克服重重障礙83
4.17 結論85
4.18 本章小結85
4.19 接下來……85
第5章 處理有雜訊的測試87
5.1 持續交付和測試88
5.2 “全民霜淇淋”停機事件89
5.3 信號與雜訊90
5.4 雜訊的成功91
5.5 失敗是如何變成雜訊的92
5.6 從雜訊到信號94
5.7 讓測試通過(變綠)95
5.8 又一次停機96
5.9 通過測試仍然可能會有雜訊97
5.10 修復測試失敗98
5.11 失敗的方式：脆弱的測試99
5.12 對失敗做出反應100
5.13 修復測試：修改代碼或測試101
5.14 重試的危險102
5.15 重試重新訪問103
5.16 為什麼要重試105
5.17 變綠並保持綠色106
5.18 結論108
5.19 本章小結108
5.20 接下來……108
第6章 讓那些緩慢的測試套件變得更快109
6.1 狗狗圖片網站110
6.2 當流水線過於簡單時111
6.3 新工程師試圖提交代碼112
6.4 測試和持續交付113
6.5 診斷：速度太慢114
6.6 測試金字塔115
6.7 先運行執行快的測試用例116
6.8 兩條流水線117
6.9 獲得正確的平衡118
6.10 改變金字塔比例119
6.11 安全地調整測試用例120
6.12 測試覆蓋率121
6.13 強制要求測試覆蓋率122
6.14 流水線中的測試覆蓋率123
6.15 在具備覆蓋率的金字塔中移動測試用例124
6.16 沿著金字塔往下移動什麼125
6.17 遺留的測試用例和FUD127
6.18 並行運行測試用例128
6.19 何時可以並行運行測試用例129
6.20 更新流水線130
6.21 還是太慢了131
6.22 分片測試，又稱並行 132
6.23 如何分片133
6.24 更複雜的分片134
6.25 分片流水線135
6.26 對流覽器測試套件進行分片136
6.27 流水線中的分片137
6.28 狗狗圖片網站的流水線138
6.29 結論142
6.30 本章小結142
6.31 接下來……142
第7章 在正確的時間發出正確的信號143
7.1 CoinExCompare網站144
7.2 代碼變更的生命週期145
7.3 僅在代碼合併前進行的CI146
7.4 代碼變更出錯的時間線147
7.5 僅在合併前運行的CI未命中缺陷148
7.6 兩張圖的故事：默認為7天149
7.7 兩張圖的故事：默認為30天150
7.8 衝突並不是總會被發現151
7.9 單元測試呢152
7.10 PR觸發器仍然會讓缺陷潛入153
7.11 合併前以及合併後的CI154
7.12 選項1：定期運行CI155
7.13 選項1：設置定期運行的CI156
7.14 選項2：要求特性分支是最新的157
7.15 選項2：成本是多少158
7.16 選項3：自動合併CI159
7.17 選項3：使用最新的主分支運行CI160
7.18 選項3：合併事件161
7.19 選項3：合併佇列162
7.20 選項3：CoinExCompare網站的合併佇列163
7.21 哪裡還會發生錯誤165
7.22 測試脆弱性和PR觸發的CI166
7.23 通過定期測試捕獲脆弱的測試167
7.24 缺陷和構建168
7.25 CI與構建和部署169
7.26 使用相同的邏輯構建和部署170
7.27 通過構建改進CI流水線171
7.28 重新審視代碼變更時間表172
7.29 結論174
7.30 本章小結174
7.31 接下來……174
第Ⅲ部分 讓交付變得簡單175
第8章 輕鬆交付從版本控制出發177
8.1 回到Watch Me Watch專案178
8.2 DORA指標179
8.3 如果我不運行服務呢181
8.4 Watch Me Watch 與精英效能團隊183
8.5 給Watch Me Watch提升速率184
8.6 與AllCatsAllTheTime集成 185
8.7 主幹開發186
8.8 特性增量式交付187
8.9 跳過測試的提交188
8.10 代碼評審和“不完整”的代碼189
8.11 保持這個勢頭191
8.12 提交不完整的代碼192
8.13 評審進行中的代碼193
8.14 與此同時，讓我們回到端到端測試194
8.15 可見的好處195
8.16 不斷縮短的變更前置時間197
8.17 繼續AllCatsAllTheTime開發198
8.18 部署視窗和代碼凍結199
8.19 速率提高200
8.20 結論201
8.21 本章小結201
8.22 接下來……201
第9章 安全可靠的構建203
9.1 Top Dog Maps204
9.2 當構建流程僅僅記錄在文檔中時205
9.3 安全和可靠構建的屬性206
9.4 始終可發佈208
9.5 自動化構建209
9.6 構建即代碼210
9.7 使用CD服務211
9.8 臨時構建環境212
9.9 Miguel的計畫213
9.10 從純文檔到擁有版本控制的腳本 214
9.11 自動化容器化構建215
9.12 安全和可靠的構建流程217
9.13 介面的變更和導致的缺陷219
9.14 當構建產生缺陷時220
9.15 構建與溝通221
9.16 語義化版本控制222
9.17 版本控制的重要性223
9.18 又一次故障！225
9.19 構建時依賴導致的錯誤226
9.20 鎖定依賴項版本227
9.21 僅僅鎖定版本還不足夠228
9.22 鎖定雜湊值229
9.23 結論231
9.24 本章小結231
9.25 接下來……231
第10章 可信賴的部署233
10.1 部署困擾不斷234
10.2 DORA的穩定性指標235
10.3 Plenty of Woofs的DORA指標237
10.4 減少部署頻率嗎238
10.5 增加部署頻率嗎239
10.6 每日部署與故障240
10.7 增加部署頻率的步驟241
10.8 修復流程中的問題242
10.9 滾動更新243
10.10 通過滾動更新修復缺陷244
10.11 回滾245
10.12 回滾策略 = 即時改善246
10.13 回滾策略實戰248
10.14 藍綠部署249
10.15 使用藍綠部署加速故障恢復時間250
10.16 金絲雀發佈更快且更穩定251
10.17 金絲雀部署的前提條件252
10.18 金絲雀發佈的基線254
10.19 金絲雀發佈的服務恢復時間255
10.20 增加部署頻率257
10.21 每日金絲雀發佈策略下的DORA指標258
10.22 持續部署259
10.23 使用持續部署的時機260
10.24 強制性的QA階段261
10.25 QA與持續部署262
10.26 精英效能團隊264
10.27 結論265
10.28 本章小結265
10.29 接下來……265
第Ⅳ部分 設計持續交付267
第11章 啟動包：從零到CD269
11.1 啟動包：概覽270
11.2 回顧：通用的CD流水線任務271
11.3 典型的發佈流水線272
11.4 典型的CI流水線273
11.5 兩條都帶觸發器的流水線274
11.6 綠地項目：邁向CD276
11.7 Gulpy277
11.8 綠地項目：從零到CD278
11.9 第一步：它能構建嗎279
11.10 選擇CD系統280
11.11 建立初始的自動化281
11.12 代碼的狀態：靜態代碼檢查282
11.13 代碼的狀態：單元測試283
11.14 代碼的狀態：覆蓋率284
11.15 超越CI：發佈285
11.16 部署286
11.17 擴展測試287
11.18 集成測試和端到端測試的任務288
11.19 完成CI流水線289
11.20 Gulpy完整的流水線290
11.21 遺留項目：邁向CD291
11.22 Rebellious Hamster292
11.23 第一步：確定增量目標的優先順序293
11.24 首先關注痛點294
11.25 Rebellious Hamster的痛點295
11.26 知道何時出現了問題296
11.27 隔離並添加測試297
11.28 具有更多測試的遺留項目流水線298
11.29 使部署更加自動化299
11.30 創建發佈流水線300
11.31 Rebellious Hamster的發佈流水線301
11.32 Rebellious Hamster的完整流水線302
11.33 結論303
11.34 本章小結303
11.35 接下來……303
第12章 腳本也是代碼305
12.1 Purrfect Bank306
12.2 CD的問題307
12.3 Purrfect Bank的CD概覽308
12.4 支付組織的Bash腳本庫309
12.5 交易服務流水線310
12.6 從一個大腳本演化311
12.7 設計良好任務的原則312
12.8 打破巨型任務313
12.9 更新後的交易服務流水線314
12.10 調試Bash庫315
12.11 調查Bash庫的缺陷316
12.12 為什麼會引入這個缺陷317
12.13 Bash的作用318
12.14 何時Bash不太好319
12.15 shell腳本與通用語言321
12.16 從shell腳本到通用程式設計語言322
12.17 遷移計畫323
12.18 從Bash庫到擁有Bash的任務324
12.19 任務內的可重用Bash325
12.20 從Bash到Python326
12.21 任務即代碼327
12.22 CD腳本也是代碼328
12.23 結論329
12.24 本章小結329
12.25 接下來……329
第13章 流水線設計331
13.1 PetMatch332
13.2 匹配服務CD流水線333
13.3 CD流水線問題334
13.4 端到端測試流水線335
13.5 端到端測試流水線和錯誤336
13.6 最終行為337
13.7 圖形化最終部分338
13.8 匹配服務流水線中的最終行為339
13.9 端到端測試流水線和速度340
13.10 並存執行任務341
13.11 端到端測試流水線和測試速度342
13.12 並存執行和測試分片343
13.13 帶有分片的端到端測試流水線344
13.14 端到端測試流水線和信號345
13.15 單一CI流水線346
13.16 發佈流水線與信號347
13.17 CI流水線的差異348
13.18 合併流水線349
13.19 發佈流水線350
13.20 發佈流水線中的硬編碼351
13.21 通過參數化複用流水線352
13.22 使用可重用的流水線353
13.23 更新後的流水線354
13.24 解決PetMatch的CD問題355
13.25 期待的CD功能356
13.26 結論357
13.27 本章小結357
13.28 接下來……357
附錄359
附錄A -- CD系統361
附錄B -- 版本控制系統371
|
