超激效：零Bug軟體開發

【推薦序】

許多工學院學生都上過實習課，會在工廠內真實地體會車、銑、刨、磨、鑽、鑄、鍛、焊等諸多生產製程，同時也會領略到管線生產的高效和有序。實際上設定管理就是保障這些製程過程按生產大綱的安排，平行而有序地開展，最後將原材料變為成品的關鍵方法。但軟體畢竟和製造業產品或硬體不同，軟體是「軟」的，靈活性高，而且易變。因此，如何了解軟體設定管理，並進而把握軟體設定管理的內在規律，真正使軟體設定管理造成為軟體發佈保駕護航的作用，的確是值得業界仔細思考和研究的課題。

從流程角度看，軟體設定管理是整個軟體開發生命週期中一個非常核心的管理過程。設定管理實際貫穿了從需求分析、架構設計、專案管理、開發、整合建構、測試，以及上線的全過程。這一過程不僅有關巨觀的專案進度控制、設定管理標準及計畫、多地點開發規劃等，也包含更細粒度的分支模型、建構及整合方式、變更處理流程，還包含微觀的與開發人員直接相關的版本控制、差異比較與歸併等。絕不誇張地講，軟體設定管理是一種「八面玲瓏」的技術或藝術，而讀者可以從本書中切實感受到這一點。當開發人員從設定管理工具的版本樹中靜靜欣賞自己作品的成形軌跡時，當整合人員從元件基準線樹把握整個應用元件的里程碑脈絡時，當專案管理人員面對缺陷發展趨勢以判斷產品發佈時機時，當建構生產人員順利將正確版本的原始程式碼從版本函數庫中取出、建構並在生產系統投產時，設定管理及相關工具不僅僅是這些人員的有力幫手，而且隨著時間的演進它帶給大家更多的將是一份信任和感動！

從人員角度看，軟體設定管理人員在軟體企業中具有非常重要的作用，絕不是許多人頭腦中的文件管理員、檔案管理員或什麼其他的人員。他們是軟體企業中所有軟體資產的管理員，是最洞悉軟體整個開發及變更過程並參與其設計的關鍵人員，是能與專案經理/ 人員、品質保障經理/ 人員、軟體分析/設計/開發/建構/測試人員充分溝通並與之打成一片的「公關」人員，是了解作業系統管理、網路管理、各種開發語言和環境、深諳軟體過程改進理論和相關工具的技術人員。透過本書，讀者可以加深對設定管理的了解，加強企業設定管理的相關工作，重視設定管理人員的培養和加強。

全書儘管只有三百餘頁，但卻深入淺出地道出了與設定變更管理相關

的多個基本概念，如版本控制、設定管理、缺陷追蹤與變更管理、建構、元件、整合、分支等。同時書中根據不同實際場景列出了業界的最佳做法，而且處處滲透了作者在軟體設定管理方面的心得，舉例來說，對分支運用的分析、對元件多工的了解和實作、對於整合過程及整合責任的清晰說明等。並且，本書結合工具（ClearCase、ClearQuest、Subversion、Bugzilla 等）簡單明了地指出了目前流行的設定工具是如何實現這些最佳做法的。可以看出本書是作者多年專注於軟體設定管理理論和實作的結晶，書中不少觀點實際上也代表了包含我在內的很多軟體設定管理相關從業人員的感受和心聲，是值得所有軟體開發從業人員仔細閱讀、細細品味及隨時參考的好書！

非常感謝董越先生在緊張工作之餘為大家所做的切切實實的貢獻！

IBM 中國有限公司軟體部Rational 軟體北方區技術負責人 李紀華

【推薦序】

許多工學院學生都上過實習課，會在工廠內真實地體會車、銑、刨、磨、鑽、鑄、鍛、焊等諸多生產製程，同時也會領略到管線生產的高效和有序。實際上設定管理就是保障這些製程過程按生產大綱的安排，平行而有序地開展，最後將原材料變為成品的關鍵方法。但軟體畢竟和製造業產品或硬體不同，軟體是「軟」的，靈活性高，而且易變。因此，如何了解軟體設定管理，並進而把握軟體設定管理的內在規律，真正使軟體設定管理造成為軟體發佈保駕護航的作用，的確是值得業界仔細思考和研究的課題。

從流程角度看，軟體設定管理是整個軟體開...

上篇 基本話題
Chapter 1 惱人不休的問題：什麼是軟體設定管理
1.1 問題的引出
1.2 有那麼一種管理
1.3 為什麼稱做設定管理
1.4 其他一些比喻
Chapter 2 基本的版本控制：記錄歷史並防止混亂
2.1 即使只有一個開發人員
2.2 建立公共儲存區
2.3 防止版本覆蓋
2.4 行話
Chapter 3 當代版本控制方法
3.1 變更集合的概念
3.2 以變更集合為單位修改程式並交付
3.3 反方向：適時更新工作區
3.4 原始程式碼的整體版本
3.5 分散式版本控制
Chapter 4 整合：關注整體品質
4.1 整合的概念
4.2 保障交付的品質
4.3 狹義整合的步驟
4.4 在基準線產生之後
4.5 品質保障：整合前、整合中、整合後
Chapter 5 從原始程式碼到執行中的程式
5.1 管理產生轉換過程和相關資產
5.2 保障建構的可重複性
5.3 全量建構和增量建構
5.4 讓建構更快
5.5 安裝套件的版本控制
5.6 管理測試執行環境
Chapter 6 邁向持續整合
6.1 及早和經常地整合，持續整合
6.2 化繁為簡
6.3 全程自動化
6.4 快！快！快！
6.5 多層整合：當團隊規模擴大以後
Chapter 7 分支：減少等待，分頭工作
7.1 檔案級分支
7.2 產品級分支
7.3 典型應用：實現多層整合
7.4 溫故而知新：實現隔離與共用
7.5 分支的其他典型應用
7.6 公共版本函數庫中的分支
7.7 私有版本函數庫中的分支
Chapter 8 管理文件
8.1 文件的標識和儲存
8.2 附帶的說明資訊
8.3 趨勢：Wiki
8.4 趨勢：資料檔案和資料庫
Chapter 9 追蹤缺陷，直到消滅
9.1 別讓發現的缺陷跑掉
9.2 狀態轉換圖
9.3 準確記錄，便於修復
9.4 消滅它？立刻消滅它？
9.5 分析統計缺陷相關資料
9.6 連結缺陷記錄與變更集合
Chapter 10 管理變更
10.1 管理增強
10.2 管理特性
10.3 瀑布模型中的變更
10.4 影響變更管理的因素
10.5 控制產品版本間的差異
10.6 表達產品版本間的差異
Chapter 11 玄妙的學院派
11.1 設定識別
11.2 設定控制
11.3 設定狀態報告
11.4 設定稽核
11.5 一些軟體研發模型中的設定管理


下篇 複雜場景中的設定管理
Chapter 12 用分支實現重疊
12.1 更新版本
12.2 多工另一條分支上的改動
12.3 甚至早在1.0 版發佈之前
12.4 甚至為了重要的內部版本
12.5 甚至為了每次整合
12.6 雙分支結構
12.7 都是重疊
Chapter 13 用分支實現變形
13.1 什麼是變形
13.2 用分支支援變形
13.3 隨主幹繼續演進
13.4 把公共改動放到主幹上
13.5 變更管理對重疊和變形的支援
13.6 歷史版本與變形版本的命名
Chapter 14 用設定實現變形
14.1 在建構時讀取設定資訊
14.2 安裝和執行時期讀取設定資訊
14.3 資源與資料
14.4 何時使用哪種方法
14.5 設定對重疊的支援
Chapter 15 用元件的組合實現變形
15.1 雛形：平台加應用
15.2 在不同階段組裝
15.3 複合基準線
15.4 複合分支
15.5 實現軟體重用：分支、設定、元件相結合
15.6 實現軟體重用：架構、過程和組織
Chapter 16 支援多地點開發
16.1 何時出現多地點開發
16.2 主要困難和解決方法
16.3 離線工作模式
16.4 遠端存取模式
16.5 當地版本函數庫模式
16.6 唯讀模式
16.7 多地點開發中的變更管理
Chapter 17 支援跨組織合作
17.1 從開放原始碼到外包
17.2 管理協力廠商資產
17.3 本機記錄協力廠商原始程式碼的演進
17.4 再加上本機的改造
17.5 共同開發
Chapter 18 管理軟體部署
18.1 安裝套件的儲存和管理
18.2 管理安裝過程
18.3 記錄執行系統組態
18.4 管理變更請求
18.5 管理網站
Chapter 19 軟體設定管理實施
19.1 不同階段，不同挑戰
19.2 如何完成一項改進
19.3 在一個專案的生命週期中
19.4 平衡集權與自治
19.5 管理許多的專案
19.6 軟體設定管理團隊的組織結構
結語 建議務實的精神
附錄 相關工具索引

上篇 基本話題
Chapter 1 惱人不休的問題：什麼是軟體設定管理
1.1 問題的引出
1.2 有那麼一種管理
1.3 為什麼稱做設定管理
1.4 其他一些比喻
Chapter 2 基本的版本控制：記錄歷史並防止混亂
2.1 即使只有一個開發人員
2.2 建立公共儲存區
2.3 防止版本覆蓋
2.4 行話
Chapter 3 當代版本控制方法
3.1 變更集合的概念
3.2 以變更集合為單位修改程式並交付
3.3 反方向：適時更新工作區
3.4 原始程式碼的整體版本
3.5 分散式版本控制
Chapter 4 整合：關注整體品質
4.1 整合的概念
4.2 保障交付的品質
4.3 狹義整合的步驟...