本書是針對《Continuous Delivery中文版:利用自動化的建置、測試與部署完美創造出可信賴的軟體發佈》所撰寫的2.0版。它「重新定義」了持續交付,增補了組織管理和架構兩個維度,輔助以真實案例,對諸多持續交付的原則和實踐加以解讀,並對持續交付過程中的取捨原則加以論述。
本書分三個部分。第一部分作者根據自己近十年的工作及諮詢經歷,不斷總結、提煉和反思,對原有的持續交付進行了修正,重新定義持續交付為實作戰略目標的能力,並引入持續交付的能力模型;第二部分闡述打造持續交付能力所需遵守的原則,包括基礎原則、組織原則和架構原則;第三部分透過多個網際網路公司案例的解讀,闡述如何根據目前的狀況加以運用原則,並對最佳實踐進行取捨,快速達到組織能力目標。
本書適合大型網際網路公司的技術VP、技術負責人,中小型網際網路公司的CTO、技術VP、研發/測試/維運負責人、主管,以及組織變革者閱讀。
◆◇大師推薦◇◆
喬梁曾與各類組織合作,幫助它們實施持續交付並實作其效益。我想不出比喬梁更合適的人選,來寫一本關於如何根據實際經驗實作這些想法的書。希望本書的每位讀者都能在提高軟體交付能力的不斷嘗試中取得圓滿成功,並利用這種能力來建置更好的產品和服務,以及更快樂、更高效率的團隊。
──Jez Humble
《Continuous Delivery中文版》一書作者,DORA聯合創始人兼CTO
作者簡介:
喬梁
為博碩出版之暢銷書籍《Continuous Delivery中文版:利用自動化的建置、測試與部署完美創造出可信賴的軟體發佈》的譯者。敏思特顧問公司聯合創始人、持續交付領域專家、著名敏捷與精實轉型導師、擔任騰訊外聘高級研發管理顧問。擁有多年IT從業經驗,曾就職於百度、Nokia等國內外知名軟體公司,並先後擔任騰訊、搜狐暢遊等多家網際網路公司的高級管理顧問,幫助多個產品線取得業務上的成功突破,曾為華為、上汽等非網際網路軟體企業提供敏捷轉型諮詢服務,指導解決組織轉型與研發管理方面的相關問題。
目錄
Chapter 01 持續交付 2.0
1.1 軟體工程發展概述
1.1.1 瀑布式軟體開發
1.1.2 敏捷軟體開發
1.1.3 DevOps 運動
1.1.4 持續交付 1.0
1.2 持續交付 2.0
1.2.1 精實思想
1.2.2 雙環模型
1.2.3 4 個核心原則
1.2.4 持續交付七巧板
1.3 小結
Chapter 02 價值探索環
2.1 探索環的意義
2.2 探索環的4 個關鍵環節
2.2.1 提問
2.2.2 鎖定
2.2.3 共創
2.2.4 精煉
2.3 工作原則
2.3.1 分解並快速試誤
2.3.2 一次只驗證一點
2.3.3 允許失敗
2.4 共創與精煉的常用方法
2.4.1 裝飾窗方法
2.4.2 最小可行特性法
2.4.3 特區法
2.4.4 定向探索法
2.4.5 稻草人法
2.4.6 最小可行產品法
2.5 實施注意事項
2.6 小結
Chapter 03 快速驗證環
3.1 驗證環的目標
3.2 驗證環的4個關鍵環節
3.2.1 建置
3.2.2 執行
3.2.3 監測
3.2.4 決策
3.3 工作原則
3.3.1 品質內建
3.3.2 消除等待
3.3.3 重覆事務自動化
3.3.4 監測一切
3.4 小結
Chapter 04 持續交付 2.0 的組織文化
4.1 安全、信任與持續改善
4.1.1 失敗是安全的
4.1.2 相互信任
4.1.3 持續改善
4.2 文化塑造四步法
4.2.1 行為決定文化
4.2.2 Google的工程師品質文化
4.2.3 Etsy的持續試驗文化
4.3 行動原則
4.3.1 價值導向
4.3.2 快速驗證
4.3.3 持續學習
4.4 度量原則
4.4.1 度量指標的4類屬性
4.4.2 度量的目標是改善
4.5 「改善套路」進行持續改進
4.6 小結
Chapter 05 持續交付的軟體系統架構
5.1 「大系統小做」原則
5.1.1 持續交付架構要求
5.1.2 系統拆分原則
5.2 常見架構模式
5.2.1 微核架構
5.2.2 微服務架構
5.2.3 單體應用
5.3 架構改造實施模式
5.3.1 拆遷者模式
5.3.2 絞殺者模式
5.3.3 修繕者模式
5.3.4 資料庫的拆分方法
5.4 小結
Chapter 06 業務需求協作管理
6.1 產品版本週期概述
6.1.1 準備期
6.1.2 交付期
6.2 需求拆分的利與弊
6.2.1 需求拆分的好處
6.2.2 需求拆分的成本
6.3 需求拆分方法
6.3.1 需求的來源
6.3.2 技術債也是需求
6.3.3 參與需求拆分的角色
6.3.4 不平等的INVEST原則
6.3.5 五大拆分技法
6.3.6 七大組成部分
6.4 需求分析與管理工具集
6.4.1 使用者故事地圖
6.4.2 使用者故事樹
6.4.3 依賴關係圖
6.4.4 需求管理數位化平台
6.5 團隊協作管理工具
6.5.1 團隊共享日曆
6.5.2 團隊回顧
6.5.3 可視化故事牆
6.5.4 明確「完成」的定義
6.5.5 持續整合
6.5.6 故事驗證
6.6 小結
Chapter 07 部署流水線原則與工具設計
7.1 簡單的部署流水線
7.1.1 簡單的產品研發流程
7.1.2 初始部署流水線
7.1.3 流水線執行狀態解析
7.2 部署流水線的設計與使用
7.2.1 流水線的設計原則
7.2.2 團隊的協作紀律
7.3 部署流水線平台的構成
7.3.1 工具鏈整體架構
7.3.2 平台應當具備的基本能力
7.3.3 工具鏈建設策略
7.4 基礎支撐服務的雲化
7.4.1 基礎支撐服務的協作過程解析
7.4.2 編譯建置管理服務
7.4.3 自動化測試管理服務
7.4.4 軟體部署管理服務
7.4.5 基礎環境管理服務
7.5 企業製品庫的管理
7.5.1 製品庫的分類
7.5.2 製品庫的管理原則
7.6 各式各樣的部署流水線
7.6.1 多元件的部署流水線
7.6.2 個人部署流水線
7.6.3 部署流水線的不斷演進
7.7 為開發者建置自助式工具
7.8 小結
Chapter 08 利於整合的分支策略
8.1 版本控制系統的使用目的
8.1.1 集中式版本控制系統
8.1.2 分散式版本控制系統
8.1.3 版本控制系統中的基本概念
8.2 常見分支開發模式
8.2.1 主線開發,主線發佈
8.2.2 主線開發,分支發佈
8.2.3 分支開發,主線發佈
8.3 分支模式的演化
8.3.1 三駕馬車分支模式
8.3.2 Gitflow分支模式
8.3.3 GitHubFlow分支模式
8.4 分支策略的選擇
8.4.1 版本發佈模式
8.4.2 分支策略與發佈週期的關係
8.5 小結
Chapter 09 持續整合
9.1 起源與定義
9.1.1 原始定義
9.1.2 一次整合程序
9.2 六步提交法
9.2.1 4個關鍵點
9.2.2 同步與非同步模式
9.2.3 自查表
9.3 速度與品質的權衡
9.3.1 分級建置
9.3.2 多人同時提交的建置
9.3.3 雲端平台的威力
9.4 在團隊中實施持續整合實踐
9.4.1 快速建立團隊的持續整合實踐
9.4.2 分支策略與部署流水線
9.5 常見的實施問題
9.5.1 工程師的開發習慣
9.5.2 視而不見的掃描問題
9.5.3 自動化測試案例的缺乏
9.6 小結
Chapter 10 自動化測試策略與方法
10.1 自動化測試的自身定位
10.1.1 自動化測試的優勢
10.1.2 自動化測試所需的投入
10.2 突破傳統自動化測試的困境
10.2.1 傳統自動化測試的特點
10.2.2 自動化測試的分層
10.2.3 不同類型的測試金字塔
10.3 自動化測試的實施策略
10.3.1 增加自動化測試案例的著手點
10.3.2 提高自動化測試的執行次數
10.3.3 良好自動化測試的特徵
10.3.4 共享自動化測試的維護職責
10.3.5 程式碼測試覆蓋率
10.4 用戶驗收自動化測試要點
10.4.1 先搭建分層框架
10.4.2 測試案例數應保持少量
10.4.3 為自動化測試案例預留API
10.4.4 為除錯做好準備
10.4.5 測試資料的準備
10.5 其他品質檢查方法
10.5.1 差異批註測試方法
10.5.2 程式碼規範檢查與程式碼動靜態檢測
10.5.3 AI在測試領域的應用
10.6 小結
Chapter 11 軟體設置管理
11.1 將一切納入設置管理
11.1.1 設置管理目標
11.1.2 設置管理的範圍
11.1.3 軟體設置管理原則
11.2 軟體套件的版本管理
11.2.1 套件管理的反模式
11.2.2 集中式套件管理服務
11.2.3 軟體套件的元資訊
11.3 套件依賴管理
11.3.1 顯式宣告依賴
11.3.2 自動管理依賴
11.3.3 減少複雜依賴
11.4 環境基礎設施管理
11.4.1 環境準備的4種狀態
11.4.2 領域專屬語言的應用程式
11.4.3 環境基礎設施即程式碼
11.5 軟體設置項目的管理
11.5.1 binary與設置項目的分離
11.5.2 設置資訊的版本管理
11.5.3 設置項目的儲存組織方式
11.5.4 設置漂移與治理
11.6 不可變基礎設施與雲端應用
11.6.1 實作不可變基礎設施
11.6.2 雲端原生應用程式
11.6.3 優勢與挑戰
11.7 資料的版本管理
11.7.1 資料庫結構變更
11.7.2 資料檔案
11.8 需求與原始程式碼的版本關聯
11.9 小結
Chapter 12 低風險發佈
12.1 高頻發佈是一種趨勢
12.1.1 網際網路企業的高頻發佈
12.1.2 獲益與成本共存
12.2 降低發佈風險的方法
12.2.1 藍綠部署
12.2.2 滾動部署
12.2.3 金絲雀發佈與灰度發佈
12.2.4 暗部署
12.3 高頻發佈支撐技術
12.3.1 功能開關技術
12.3.2 資料移轉技術
12.3.3 抽象分支方法
12.3.4 升級替代還原
12.4 影響發佈頻率的因素
12.5 小結
Chapter 13 監測與決策
13.1 生產監測範圍
13.1.1 後台服務的監測
13.1.2 分發軟體的監測
13.2 資料監測體系
13.2.1 收集與處理
13.2.2 資料的標準化
13.2.3 監測資料體系及其能力衡量
13.3 問題處理體系
13.3.1 告警海洋與智慧化管理
13.3.2 問題處理是一個學習過程
13.4 生產環境測試
13.4.1 測試活動扁平化趨勢
13.4.2 生產環境中的測試
13.4.3 混沌工程
13.5 向東,還是向西
13.6 小結
Chapter 14 大型網際網路團隊的 FT 化
14.1 簡介
14.1.1 改進前狀態
14.1.2 改進後狀態
14.2 改進方法論
14.2.1 指導思想
14.2.2 改進步驟
14.3 改進的歷程
14.3.1 架構解耦
14.3.2 組織解耦
14.3.3 研發流程再造
14.3.4 自動化一切
14.4 小結
Chapter 15 小團隊逆襲之旅
15.1 背景簡介359
15.1.1 改進前的「死亡行軍」之旅
15.1.2 改進後的無缺陷交付
15.2 改進方法論
15.2.1 指導思想
15.2.2 試點團隊的選擇
15.3 第一階段:研發準備期
15.3.1 功能簡介與需求拆分
15.3.2 架構設計與需求依賴識別
15.3.3 工作量估算與排期
15.4 第二階段:軟體交付期
15.4.1 透過可視化看板改進工作流程
15.4.2 無缺陷交付
15.4.3 主線開發與持續整合
15.4.4 測試活動左移
15.4.5 程式碼審核
15.4.6 關注結果,更要關注過程
15.5 小結
Chapter 16 研發推動的DevOps
16.1 改進的關鍵點
16.1.1 改進方法論
16.1.2 定義改進目標
16.2 第一階段:敏捷101
16.2.1 做個可靠的計劃
16.2.2 開發階段啟航
16.2.3 對過程品質的約束
16.2.4 階段性改進點
16.3 第二階段:DevOps轉型
16.3.1 與維運人員的「衝突」
16.3.2 高頻部署發佈中的具體障礙
16.3.3 整體解決方案的設計
16.3.4 DevOps階段的團隊改變
16.4 小結
Appendix A 軟體工程的三次進化
A.1 軟體工程的誕生
A.1.1 軟體危機
A.1.2 瀑布式軟體開發模型
A.2 二次進化:敏捷開發
A.2.1 前奏──螺旋模型
A.2.2 敏捷宣言的誕生
A.2.3 敏捷軟體開發方法的演化
A.2.4 敏捷軟體開發方法小結
A.2.5 TPS啟發下的軟體開發方法
A.3 三次進化:DevOps
A.3.1 DevOps運動的興起
A.3.2 持續交付的誕生
A.4 小結
Appendix B 排序法做相對估算
B.1 排序法相對估算
B.2 相對排序法的操作流程
B.3 小結
Chapter 01 持續交付 2.0
1.1 軟體工程發展概述
1.1.1 瀑布式軟體開發
1.1.2 敏捷軟體開發
1.1.3 DevOps 運動
1.1.4 持續交付 1.0
1.2 持續交付 2.0
1.2.1 精實思想
1.2.2 雙環模型
1.2.3 4 個核心原則
1.2.4 持續交付七巧板
1.3 小結
Chapter 02 價值探索環
2.1 探索環的意義
2.2 探索環的4 個關鍵環節
2.2.1 提問
2.2.2 鎖定
2.2.3 共創
2.2.4 精煉
2.3 工作原則
2.3.1 分解並快速試誤
2.3.2 一次只驗證一點
2.3.3 允許失敗
2.4 共創與精煉的常用方法
2.4.1 裝飾窗方法
2.4.2 最小可行特性法
2.4.3 特區法
...
購物須知
退換貨說明:
會員均享有10天的商品猶豫期(含例假日)。若您欲辦理退換貨,請於取得該商品10日內寄回。
辦理退換貨時,請保持商品全新狀態與完整包裝(商品本身、贈品、贈票、附件、內外包裝、保證書、隨貨文件等)一併寄回。若退回商品無法回復原狀者,可能影響退換貨權利之行使或須負擔部分費用。
訂購本商品前請務必詳閱退換貨原則。