掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
持續交付圖解 版權信息
- ISBN：9787302679219
- 條形碼：9787302679219 ; 978-7-302-67921-9
- 裝幀：平裝-膠訂
- 冊數：暫無
- 重量：暫無
- 所屬分類：>
持續交付圖解 本書特色
《持續交付圖解》是大型軟件研發從業者經驗傳授的經典著作，Christie從MVP故事出發，利用敏捷迭代的方法將持續集成、持續構建、持續交付等復雜的概念融入全書的敘述中。難能可貴的是，這些方法均巧妙地集成到了一個創業公司不斷升級打怪的故事中，作者的敘述讓每位讀者不僅知其然且知其所以然，我想這就是本書*難能可貴的價值。這些重要概念的上下文才是諸位看官決定是否采納，以及如何采納那些當下流行技術詞匯的重要依據。
持續交付圖解 內容簡介
"請讓你的代碼庫隨時保持可發布狀態。持續交付流水線可以實現自動化版本控制、自動測試和自動部署，將開發人員的干預降至**。掌握持續交付的工具和實踐，你將能夠快速且一致地添加功能和推送更新。 《持續交付圖解》是建立和使用持續交付流水線的友好指南。每一章都介紹了在設置CD系統時將面臨的不同場景，包括自動擴展和測試遺留應用程序等現實問題的示例。作者Christie Wilson采用與具體工具無關的方法，通過插圖、清晰的解釋和實踐練習來指導你的每一步學習。 主要內容 ?為新項目和遺留項目設計有效的CD流水線 ?確保你的流水線在適當的時候發出正確的信號 ?將版本控制作為真相的來源 ?安全地自動化部署"
持續交付圖解持續交付圖解 前言
當我和David Farley合著Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley，2010)一書時，我們認為書中描述的我們多年實踐的原則“一種現代的、整體的軟件交付方法”會為使用它的團隊和組織帶來巨大好處。多個研究項目(包括我參與的由Nicole Forsgren博士主導，并在本書第8章和第10章描述的項目)表明，它可以帶來更高的質量和穩定性，以及更快的交付速度。
盡管持續集成和持續交付(Continuous Integration and Continuous Delivery，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
展開全部
持續交付圖解 作者簡介
Christie Wilson是一名軟件工程師。她經常在Kubecon、OSCON、QCon、PyCon等會議上就CI/CD及相關主題發表演講。Christie的職業生涯始于移動端Web應用開發。在從事AAA游戲的后端開發時，她編寫的功能通常在系統大規模發布后才會被許多人同時使用。為此，她構建了負載和系統測試平臺。
憑借處理復雜部署環境、核心關鍵系統和應對突發流量的經驗，她加入了Google并從事相關方向的工作。在Google，她為AppEngine、boot-strapped Knative構建了內部生產力工具，并創建了Tekton，這是一個基于Kubernetes(目前有65家以上的公司參與)構建的云原生CI/CD平臺。
書友推薦
- >
龍榆生：詞曲概論/大家小書
- >
我與地壇
- >
大紅狗在馬戲團-大紅狗克里弗-助人
- >
企鵝口袋書系列·偉大的思想20:論自然選擇(英漢雙語)
- >
李白與唐代文化
- >
新文學天穹兩巨星--魯迅與胡適/紅燭學術叢書(紅燭學術叢書)
- >
伊索寓言-世界文學名著典藏-全譯本
- >
【精裝繪本】畫給孩子的中國神話
本類暢銷
