配置管理最佳實踐（簡體書）

《配置管理最佳實踐》貼近實際，旨在指導配置管理從業者如何處理日常工作中需要面對的各種複雜情況。全書詳細介紹了配置管理的6個核心職能：源代碼管理、構建工程、環境配置、變更控制、發佈工程和部署。作者在書中展示了如何實施配置管理，從而可以支持軟件和系統的開發，滿足SOX、SAS-70等合規準則的要求，提前考慮新興的IEEE/ISO 12207等標準，同時還可以和最新的ITIL、COBIT 和CMMI等框架集成到一起。
《配置管理最佳實踐》對於任何與配置管理相關的工作人員來說都是一本必不可少的參考書。從CTO到CIO，再到開發人員、質量保證工程師、項目經理、軟件工程師、系統分析員、測試人員和合規專業人士，皆是如此。

第I部分 配置管理核心實踐
第1章 源代碼管理
術語和源代碼管理
源代碼管理的目標
源代碼管理的原則
1.1 為什麼源代碼管理如此重要
1.2 從哪裡開始
1.3 源代碼管理核心概念
1.3.1 建立基線和時間機器
1.3.2 保留與非保留簽出
1.3.3 沙箱和工作空間
1.3.4 變體管理
1.3.5 複製分支與增量分支
1.3.6 如何處理缺陷修復
1.3.7 流
1.3.8 合併
1.3.9 變更集
1.4 權限和需求跟蹤
1.5 管理全球分布式開發團隊
1.6 工具的選擇
1.6.1 開源軟件與商業軟件
1.6.2 產品成熟度和供應商承諾
1.6.3 可擴展性和開放的API
1.6.4 不要過度工程化源代碼管理
1.7 認識質量成本和總擁有成本
1.8 培訓
1.9 建立使用模型
1.10 實施時間和風險
1.11 建立支持過程
1.12 高級特性和授權高級用戶
結論

第2章 構建工程
構建工程的目標
構建工程的原則
2.1 為什麼構建工程如此重要
2.2 從哪裡開始
2.3 構建工程的核心概念
2.3.1 版本ID和標記可執行文件
2.3.2 不可變的版本ID
2.3.3 打上版本標記或者標簽
2.3.4 管理編譯依賴
2.3.5 獨立構建
2.4 建立構建職能的注意事項
2.4.1 推廣獨立構建
2.4.2 過度工程化構建
2.4.3 保持正直和誠實
2.4.4 隸屬研發部門引起的利益衝突
2.4.5 組織結構的選擇
2.5 構建工具評估和選擇
2.5.1 Apache Ant進入構建舞臺
2.5.2 Maven
2.5.3 Maven與Ant
2.5.4 使用Ant生成複雜構建
2.5.5 持續集成
2.5.6 持續集成系統
2.5.7 集成開發環境
2.5.8 靜態代碼分析
2.5.9 構建框架
2.5.10 構建工具的選擇
2.5.11 對比優缺點達成一致
2.6 質量和培訓成本
2.7 把構建做得更好
2.7.1 鮑勃的構建秘方
2.7.2 測試驅動的構建
2.7.3 信任但仍要核查
2.7.4 飛機的駕駛艙
2.8 構建工程師的角色
2.8.1 瞭解構建的項目
2.8.2 與開發人員合作
2.8.3 招募新人
2.9 架構是構建的基礎
2.10 建立構建過程
2.11 持續集成與每日構建
2.12 構建工程的前景
結論

第3章 環境配置
環境配置控制的目標
環境配置控制的原則
3.1 為什麼環境配置如此重要
3.2 從哪裡著手
3.3 支持代碼提升
3.4 管理配置
3.4.1 使用的是哪個數據庫
3.4.2 那筆交易發生了嗎
3.4.3 少用幾個符號
3.4.4 集中分配環境變量
3.5 建立配置管理數據庫的實際方法
3.5.1 識別和控制
3.5.2 理解環境配置
3.6 依賴於環境配置的變更控制
3.7 減少控制
3.8 管理環境
3.9 環境配置的未來
結論

第4章 變更控制
變更控制的目標
變更控制的原則
4.1 變更控制為何如此重要
4.2 變更控制從何做起
4.3 變更控制的七種類型
4.3.1 優先級
4.3.2 把關控制
4.3.3 配置控制
4.3.4 變更諮詢委員會
4.3.5 緊急變更控制
4.3.6 過程工程
4.3.7 高級管理人員監督
4.4 建立變更控制
4.5 變更控制實例
4.5.1 29分鐘變更控制會議
4.5.2 投資銀行變更控制
4.5.3 貿易公司的變更控制
4.5.4 偽造批准
4.6 時刻不要忘記風險
4.7 通過變更控制推動配置管理流程
4.8 進入/退出標準
4.9 事後審查
4.10 自我評估
結論

第5章 發佈管理
發佈管理的目標
發佈管理的原則
5.1 為什麼發佈管理如此重要
5.2 從哪裡開始
5.3 發佈管理的概念和實踐
5.3.1 可行的打包策略
5.3.2 發佈包版本識別
5.3.3 發佈版本的材料清單
5.3.4 不可變ID意味著什麼
5.4 發佈管理人類工程學
5.4.1 避免人為錯誤
5.4.2 瞭解技術
5.4.3 構建工程工具
5.4.4 避免人為錯誤
5.4.5 三步走
5.4.6 太多可變部分
5.5 發佈管理的協調職能
5.5.1 溝通發佈狀態
5.5.2 不要忘記發佈日程表
5.5.3 發佈管理和配置控制
5.6 需求跟蹤
5.7 將發佈管理提升到新的層次
5.7.1 使用加密技術簽名代碼
5.7.2 操作系統對發佈管理的支持
5.7.3 改善你的發佈管理過程
結論

第6章 部署
部署的目標
部署的原則
6.1 為什麼部署很重要
6.2 從哪裡開始
6.3 實踐和實例
6.3.1 發佈中轉區
6.3.2 腳本控制發佈過程
6.3.3 部署框架
6.3.4 如果鮑勃犯了個錯誤怎麼辦
6.3.5 細說存儲庫
6.3.6 審計發行版本
6.4 進行配置審計
6.5 不要忘記冒煙測試
6.6 小失誤導致大問題
6.7 溝通計劃
6.8 部署應當授權
6.9 信任也要核查
6.10 改進部署過程
結論

第Ⅱ部分 架構和硬件配置管理
第7章 為配置管理設計應用程序架構
為配置管理設計應用程序架構的目標
7.1 為什麼架構很重要
7.2 從哪裡開始
7.3 配置管理如何促進良好的架構
7.4 架構師可以從測試人員那裡學到什麼
7.5 配置管理驅動開發
7.6 應對不斷變化的架構
7.7 使用源代碼管理促進架構
7.8 培訓是關鍵
7.9 作為服務的源代碼管理
7.10 作為服務的構建工程
結論

第8章 硬件配置管理
硬件配置管理的目標
8.1 為什麼硬件配置管理的重要
8.2 從哪裡開始
8.3 當無法版本控制電路芯片時
8.3.1 配置項的任何其他名稱
8.3.2 設計規範的版本控制
8.4 不要忘記接口
8.5 瞭解依賴關係
8.6 可追溯性
8.7 部署變更到固件
8.8 硬件配置管理的未來
結論

第Ⅲ部分 配置管理中人的因素
第9章 合理精簡過程
合理精簡配置管理過程的目標
9.1 為什麼合理精簡配置管理過程很重要
9.2 從哪裡開始
9.3 繁瑣的過程只會成為障礙
9.4 軟件過程改進網絡和推廣能力成熟度模型
9.5 正在消失的煩瑣過程
9.5.1 敏捷開發過程就是有用
9.5.2 開放統一過程
9.5.3 變得精益
9.5.4 希望能夠激勵人仔細瞭解精益軟件開發的一個非常簡短的描述
9.6 過程太少的危險
9.7 恰好夠用的過程改進
9.8 不要過度工程化配置管理
9.9 不要忘了技術
9.10 測試自己的過程
9.11 過程諮詢
9.12 創建一個可持續發展的結構
結論

第10章 克服變革的阻力
克服變革阻力的目的
10.1 為什麼克服變革阻力很重要
10.2 從哪裡開始
10.3 過程與企業文化相匹配
10.4 心理學和計算機程序設計相結合
10.5 從內部進行過程改進
10.6 選擇首先要解決的問題
10.7 培養團隊協作
10.8 為什麼優秀的開發人員反對過程改進
10.9 程序公正
10.10 聽取每個人的意見
10.11 展現領導能力
10.12 實施過程改進的人本身可能會成為問題
10.13 過程和技術培訓相結合
10.14 傾聽節奏
10.15 過程需要得到測試
10.16 嬰兒般的步伐和過程改進
10.17 推銷過程改進
10.18 什麼是我需要的
10.19 作為服務的過程改進
10.20 過程改進的遊擊戰術
結論

第11章 個性與配置管理：一位心理學家眼中的工作場所
瞭解個性的目的：對我而言有何用處
11.1 配置管理專業人員的個性處理
11.2 配置管理專家從個性的角度所要考慮的因素
11.2.1 溝通風格
11.2.2 男人和女人使用和解釋語言或有差異
11.2.3 有效的協商
11.2.4 信息的核實
11.2.5 信息處理的偏好
11.2.6 工作中的出生順序
11.2.7 作為領導者的長子
11.2.8 作為妥協者的老二
11.2.9 作為發起者的老么
11.2.10 獨生子
11.2.11 做你自己
11.3 心理學在工作場所的應用
11.3.1 有效的團隊協作從家庭開始
11.3.2 排球或有效協作
11.3.3 把構建工程師和測試人員嵌入開發團隊中
11.3.4 黑盒、白盒以及灰盒測試的對比
11.3.5 破壞性的小組形態
11.3.6 適合配置管理和質量檢測的位置
11.4 家庭動態
11.5 工作場所的文化和個性
11.5.1 個性和結構
11.5.2 我們已經發明了所有的好點子
11.5.3 我行我素，不守規矩
11.5.4 在保持列車運行的同時保持有效的監督
11.5.5 成功的配方
11.5.6 注意事項
結論

第12章 從錯誤中吸取教訓
從錯誤中吸取教訓的目的
12.1 從錯誤中吸取教訓的重要性
12.2 從錯誤中吸取教訓的第一步
12.3 明白我們的錯誤
12.4 我所犯的錯誤
12.4.1 缺乏大局觀
12.4.2 編寫發佈自動化腳本是一項很有挑戰性的工作
12.4.3 關於良好的進程會自我運行的思考
12.4.4 未能取得共識
12.4.5 未能在配置管理上展現領導能力
12.4.6 成為問題的一部分
12.4.7 忘記向他人尋求幫助
12.5 把錯誤變成教訓
12.5.1 明確知道如何做才能完成工作
12.5.2 獲得所需要的培訓
12.6 他人常犯的錯誤
12.6.1 象牙塔
12.6.2 沒能提高自己的技術和動手能力
12.6.3 缺乏誠實和坦然的態度
結論

第Ⅳ部分 合規、行業標準和框架
第13章 建立IT控制及合規性
建立IT控制及合規性的目標
13.1 為什麼IT控制及合規性很重要
13.2 建立IT控制及合規性的第一步
13.3 理解IT控制及合規性
13.3.1 2002年發佈的“薩班斯-奧克斯利法案”
13.3.2 內部控制的管理評估
13.3.3 發起機構委員會
13.3.4 用於IT控制框架的COBIT
13.3.5 核實並彙報管理層所做出的評估
13.3.6 1996年發佈的健康保險隱私及責任法案
13.3.7 當美國審計署來敲你門的時候
13.3.8 審計結果
13.3.9 美國審計署關於國家檔案記錄管理局的配置管理實踐的報告
13.3.10 美國電子文件檔案館的配置管理規劃
13.3.11 有待改善的領域
13.3.12 瞭解審計結果
13.3.13 美國金融管理局
13.4 必不可少的合規性要求
13.4.1 為版本發佈提供可追溯的需求
13.4.2 控制生產分離
13.5 支持配置管理最佳實踐的道德觀點
13.6 通過合規性來提高工作質量和效率
13.7 進行配置管理評估
13.7.1 評估的第一步
13.7.2 無論出現多麼糟糕的情況也要先留心去聽
結論

第14章 行業標準和框架
使用行業標準和框架的目標
14.1 為什麼標準和框架很重要
14.2 以IT控制及合規性為最佳實踐的第一步
14.3 必知的專業術語
14.3.1 配置項
14.3.2 配置標識
14.3.3 配置控制
14.3.4 接口控制
14.3.5 配置狀態統計
14.3.6 配置審計
14.3.7 分包商/供應商的管理手段
14.3.8 符合規範與違規
14.4 將這些條款應用在標準和框架裡
14.5 行業標準
14.5.1 IEEE 828——標準軟件配置管理方案
14.5.2 ISO 10007質量管理體系——配置管理的指導方針
14.5.3 ANSI/ITAA EIA-649-A——配置管理的國家統一標準
14.5.4 ISO/IEC/IEEE 12207和15288標準
14.6 行業框架
14.6.1 ISACA COBIT
14.6.2 能力成熟度模型/能力成熟度模型集成
14.6.3 itSMF的ITIL框架
14.6.4 軟件工程知識體系
14.6.5 開放統一過程（OpenUP）
14.6.6 敏捷/SCRUM
結論