持續交付2.0:業務引領的DevOps精要(精裝版)

持續交付2.0:業務引領的DevOps精要(精裝版)

《持續交付2.0:業務引領的DevOps精要(精裝版)》是2020年2月人民郵電出版社出版的圖書,作者是喬梁。

基本介紹

  • 中文名:持續交付2.0:業務引領的DevOps精要(精裝版)
  • 作者:喬梁
  • 出版社:人民郵電出版社
  • 出版時間:2020年2月
  • 頁數:345 頁
  • 定價:129 元
  • 開本:16 開
  • 裝幀:精裝
  • ISBN:9787115524638
內容簡介,圖書目錄,

內容簡介

本書“重新定義”了持續交付,增補了組織管理和架構兩個維度,輔助以真實案例,對諸多持續交付的原則和實踐加以解讀,並對持續交付過程中的取捨原則加以論述。
本書分三個部分。第一部分作者根據自己近十年的工作及諮詢經歷,不斷總結、提煉和反思,對原有的持續交付進行了修正,重新定義持續交付為實現組織戰略目標的能力,並引入持續交付的能力模型;第二部分闡述組織打造持續交付能力所需遵守的原則,包括基礎原則、組織原則和架構原則;第三部分通過多個網際網路公司案例的解讀,闡述如何根據組織的當前狀況,套用原則,並對最佳實踐進行取捨,快速達到組織能力目標。
本書適合大型網際網路公司的技術VP、技術負責人,中小型網際網路公司的CTO、技術VP、研發/測試/運維負責人、主管及骨幹,以及組織變革者閱讀。

圖書目錄

第1章 持續交付2.0 1
1.1 軟體工程發展概述 1
1.1.1 瀑布軟體開發方法 1
1.1.2 敏捷軟體開發方法 2
1.1.3 DevOps運動 3
1.1.4 持續交付1.0 4
1.2 持續交付2.0 7
1.2.1 精益思想 8
1.2.2 雙環模型 9
1.2.3 4個核心原則 11
1.2.4 持續交付七巧板 12
1.3 小結 13
第2章 價值探索環 15
2.1 探索環的意義 15
2.2 探索環的4個關鍵環節 16
2.2.1 提問 17
2.2.2 錨定 18
2.2.3 共創 20
2.2.4 精煉 23
2.3 工作原則 25
2.3.1 分解並快速試錯 25
2.3.2 一次只驗證一點 26
2.3.3 允許失敗 27
2.4 共創與精煉的常用方法 28
2.4.1 裝飾窗方法 28
2.4.2 最小可行特性法 30
2.4.3 特區法 31
2.4.4 定向探索法 31
2.4.5 稻草人法 32
2.4.6 最小可行產品法 33
2.5 實施注意事項 33
2.6 小結 36
第3章 快速驗證環 37
3.1 驗證環的目標 37
3.2 驗證環的4個關鍵環節 38
3.2.1 構建 38
3.2.2 運行 39
3.2.3 監測 40
3.2.4 決策 40
3.3 工作原則 40
3.3.1 質量內建 40
3.3.2 消除等待 41
3.3.3 重複事務自動化 44
3.3.4 監測一切 44
3.4 小結 45
第4章 持續交付2.0的企業文化 47
4.1 安全、信任與持續改善 47
4.1.1 失敗是安全的 47
4.1.2 相互信任 47
4.1.3 持續改善 48
4.2 文化塑造四步法 48
4.2.1 行為決定文化 48
4.2.2 谷歌的工程師質量文化 50
4.2.3 Etsy的持續試驗文化 51
4.3 行動原則 52
4.3.1 價值導向 53
4.3.2 快速驗證 53
4.3.3 持續學習 53
4.4 度量原則 57
4.4.1 度量指標的4類屬性 58
4.4.2 度量的目標是改善 59
4.5 “改善套路”進行持續改進 59
4.6 小結 60
第5章 持續交付的軟體系統架構 63
5.1 “大系統小做”原則 64
5.1.1 持續交付架構要求 64
5.1.2 系統拆分原則 64
5.2 常見架構模式 65
5.2.1 微核架構 65
5.2.2 微服務架構 66
5.2.3 巨石套用 67
5.3 架構改造實施模式 69
5.3.1 拆遷者模式 70
5.3.2 絞殺者模式 71
5.3.3 修繕者模式 71
5.3.4 資料庫的拆分方法 73
5.4 小結 73
第6章 業務需求協作管理 75
6.1 產品版本周期概述 76
6.1.1 準備期 76
6.1.2 交付期 77
6.2 需求拆分的利與弊 78
6.2.1 需求拆分的收益 79
6.2.2 需求拆分的成本 81
6.3 需求拆分方法 82
6.3.1 需求的來源 83
6.3.2 技術債也是需求 83
6.3.3 參與需求拆分的角色 84
6.3.4 不平等的INVEST原則 85
6.3.5 五大拆分技法 85
6.3.6 七大組成部分 87
6.4 需求分析與管理工具集 88
6.4.1 用戶故事地圖 88
6.4.2 用戶故事樹 89
6.4.3 依賴關係圖 90
6.4.4 需求管理數位化平台 90
6.5 團隊協作管理工具 90
6.5.1 團隊共享日曆 91
6.5.2 團隊回顧 92
6.5.3 可視化故事牆 93
6.5.4 明確“完成”的定義 93
6.5.5 持續集成 94
6.5.6 故事驗證 94
6.6 小結 94
第7章 部署流水線原則與工具設計 95
7.1 簡單的部署流水線 95
7.1.1 簡單的產品研發流程 95
7.1.2 初始部署流水線 96
7.1.3 流水線執行狀態解析 98
7.2 部署流水線的設計與使用 98
7.2.1 流水線的設計原則 98
7.2.2 團隊的協作紀律 100
7.3 部署流水線平台的構成 100
7.3.1 工具鏈總體架構 100
7.3.2 平台應當具備的基本能力 102
7.3.3 工具鏈建設策略 103
7.4 基礎支撐服務的雲化 103
7.4.1 基礎支撐服務的協作過程解析 104
7.4.2 編譯構建管理服務 106
7.4.3 自動化測試管理服務 107
7.4.4 軟體部署管理服務 108
7.4.5 基礎環境管理服務 109
7.5 企業製品庫的管理 110
7.5.1 製品庫的分類 110
7.5.2 製品庫的管理原則 111
7.6 多種多樣的部署流水線 111
7.6.1 多組件的部署流水線 111
7.6.2 個人部署流水線 112
7.6.3 部署流水線的不斷演進 113
7.7 為開發者構建自助式工具 114
7.8 小結 116
第8章 利於集成的分支策略 117
8.1 版本控制系統的使用目的 117
8.1.1 集中式版本控制系統 117
8.1.2 分散式版本控制系統 118
8.1.3 版本控制系統中的基本概念 120
8.2 常見分支開發模式 121
8.2.1 主幹開發,主幹發布 121
8.2.2 主幹開發,分支發布 122
8.2.3 分支開發,主幹發布 124
8.3 分支模式的演化 129
8.3.1 “三駕馬車”分支模式 129
8.3.2 Gitflow分支模式 130
8.3.3 GitHubFlow分支模式 131
8.4 分支策略的選擇 131
8.4.1 版本發布模式 131
8.4.2 分支策略與發布周期的關係 135
8.5 小結 136
第9章 持續集成 137
9.1 起源與定義 137
9.1.1 原始定義 138
9.1.2 一次集成過程 138
9.2 六步提交法 139
9.2.1 4個關鍵點 141
9.2.2 同步與異步模式 142
9.2.3 自查表 143
9.3 速度與質量的權衡 144
9.3.1 分級構建 145
9.3.2 多人同時提交的構建 145
9.3.3 雲平台的威力 146
9.4 在團隊中實施持續集成實踐 148
9.4.1 快速建立團隊的持續集成實踐 149
9.4.2 分支策略與部署流水線 151
9.5 常見的實施問題 153
9.5.1 工程師的開發習慣 154
9.5.2 視而不見的掃描問題 154
9.5.3 自動化測試用例的缺乏 154
9.6 小結 155
第10章 自動化測試策略與方法 157
10.1 自動化測試的自身定位 157
10.1.1 自動化測試的優勢 158
10.1.2 自動化測試所需的投入 159
10.2 突破傳統自動化測試的困境 160
10.2.1 傳統自動化測試的特點 161
10.2.2 自動化測試的分層 161
10.2.3 不同類型的測試金字塔 164
10.3 自動化測試的實施策略 167
10.3.1 增加自動化測試用例的著手點 167
10.3.2 提高自動化測試的執行次數 168
10.3.3 良好自動化測試的特徵 169
10.3.4 共享自動化測試的維護職責 170
10.3.5 代碼測試覆蓋率 171
10.4 用戶驗收自動化測試要點 172
10.4.1 先搭建分層框架 172
10.4.2 測試用例數應保持低位 175
10.4.3 為自動化測試用例預留API 175
10.4.4 為調試做好準備 175
10.4.5 測試數據的準備 175
10.5 其他質量檢查方法 177
10.5.1 差異批註測試方法 177
10.5.2 代碼規範檢查與代碼動靜態檢測 178
10.5.3 AI在測試領域的套用 178
10.6 小結 179
第11章 軟體配置管理 181
11.1 將一切納入配置管理 181
11.1.1 配置管理目標 181
11.1.2 配置管理的範圍 182
11.1.3 軟體配置管理原則 182
11.2 軟體包的版本管理 186
11.2.1 包管理的反模式 186
11.2.2 集中式包管理服務 187
11.2.3 軟體包的元信息 188
11.3 包依賴管理 190
11.3.1 顯式聲明依賴 190
11.3.2 自動管理依賴 192
11.3.3 減少複雜依賴 193
11.4 環境基礎設施管理 196
11.4.1 環境準備的4種狀態 196
11.4.2 領域專屬語言的套用 202
11.4.3 環境基礎設施即代碼 203
11.5 軟體配置項的管理 204
11.5.1 二進制與配置項的分離 204
11.5.2 配置信息的版本管理 205
11.5.3 配置項的存儲組織方式 206
11.5.4 配置漂移與治理 207
11.6 不可變基礎設施與雲套用 208
11.6.1 實現不可變基礎設施 208
11.6.2 雲原生套用 211
11.6.3 優勢與挑戰 211
11.7 數據的版本管理 213
11.7.1 資料庫結構變更 213
11.7.2 數據檔案 213
11.8 需求與原始碼的版本關聯 214
11.9 小結 214
第12章 低風險發布 217
12.1 高頻發布是一種趨勢 217
12.1.1 網際網路企業的高頻發布 218
12.1.2 收益與成本共存 220
12.2 降低發布風險的方法 221
12.2.1 藍綠部署 221
12.2.2 滾動部署 222
12.2.3 金絲雀發布與灰度發布 223
12.2.4 暗部署 224
12.3 高頻發布支撐技術 225
12.3.1 功能開關技術 226
12.3.2 數據遷移技術 228
12.3.3 抽象分支方法 231
12.3.4 升級替代回滾 232
12.4 影響發布頻率的因素 233
12.5 小結 234
第13章 監測與決策 235
13.1 生產監測範圍 236
13.1.1 後台服務的監測 236
13.1.2 分發軟體的監測 236
13.2 數據監測體系 237
13.2.1 收集與處理 237
13.2.2 數據的標準化 238
13.2.3 監測數據體系及其能力衡量 239
13.3 問題處理體系 241
13.3.1 告警海洋與智慧型化管理 241
13.3.2 問題處理是一個學習過程 242
13.4 生產環境測試 243
13.4.1 測試活動扁平化趨勢 243
13.4.2 生產環境中的測試 245
13.4.3 混沌工程 245
13.5 向東,還是向西 246
13.6 小結 247
第14章 大型網際網路團隊的FT化 249
14.1 簡介 249
14.1.1 改進前狀態 250
14.1.2 改進後狀態 252
14.2 改進方法論 252
14.2.1 指導思想 252
14.2.2 改進步驟 252
14.3 改進的歷程 253
14.3.1 架構解耦 253
14.3.2 組織解耦 255
14.3.3 研發流程再造 258
14.3.4 自動化一切 266
14.4 小結 267
第15章 小團隊逆襲之旅 271
15.1 背景簡介 271
15.1.1 改進前的“死亡行軍”之旅 273
15.1.2 改進後的無缺陷交付 273
15.2 改進方法論 274
15.2.1 指導思想 274
15.2.2 試點團隊的選擇 274
15.3 第一階段:研發準備期 275
15.3.1 功能簡介與需求拆分 275
15.3.2 架構設計與需求依賴識別 276
15.3.3 工作量估算與排期 277
15.4 第二階段:軟體交付期 279
15.4.1 通過可視化看板改進工作流程 279
15.4.2 無缺陷交付 286
15.4.3 主幹開發與持續集成 287
15.4.4 測試活動左移 288
15.4.5 代碼評審 288
15.4.6 關注結果,更要關注過程 289
15.5 小結 290
第16章 研發推動的DevOps 293
16.1 改進的關鍵點 295
16.1.1 改進方法論 295
16.1.2 定義改進目標 295
16.2 第一階段:敏捷101 297
16.2.1 做個靠譜的計畫 297
16.2.2 開發階段啟航 301
16.2.3 對過程質量的約束 304
16.2.4 階段性改進點 311
16.3 第二階段:DevOps轉型 312
16.3.1 與運維人員的“衝突” 313
16.3.2 高頻部署發布中的具體障礙 314
16.3.3 整體解決方案的設計 314
16.3.4 DevOps階段的團隊改變 318
16.4 小結 318
第17章 勝任力模型與組織健康度 321
17.1 組織能力三要素:流程、工具與個體 321
17.2 組織勝任力評估模型 322
17.2.1 過程維度 323
17.2.2 結果維度 323
17.3 個人勝任力培養體系 324
17.4 組織健康度 325
17.5 小結 326
附錄A 軟體工程的三次進化 327
附錄B 排序法做相對估算 341

相關詞條

熱門詞條

聯絡我們