配置管理最佳實踐

目　錄

第I部分　配置管理核心實踐　1

第1章　源代碼管理　3
術(shù)語和源代碼管理　4
源代碼管理的目標　5
源代碼管理的原則　5
1.1　為什么源代碼管理如此重要　6
1.2　從哪里開始　7
1.3　源代碼管理核心概念　8
1.3.1　建立基線和時間機器　8
1.3.2　保留與非保留簽出　9
1.3.3　沙箱和工作空間　10
1.3.4　變體管理　10
1.3.5　復制分支與增量分支　11
1.3.6　如何處理缺陷修復　11
1.3.7　流　12
1.3.8　合并　13
1.3.9　變更集　14
1.4　權(quán)限和需求跟蹤　14
1.5　管理全球分布式開發(fā)團隊　15
1.6　工具的選擇　16
1.6.1　開源軟件與商業(yè)軟件　17
1.6.2　產(chǎn)品成熟度和供應(yīng)商承諾　18
1.6.3　可擴展性和開放的API　18
1.6.4　不要過度工程化源代碼管理　19
1.7　認識質(zhì)量成本和總擁有成本　19
1.8　培訓　20
1.9　建立使用模型　21
1.10　實施時間和風險　22
1.11　建立支持過程　22
1.12　高級特性和授權(quán)高級用戶　23
結(jié)論　23

第2章　構(gòu)建工程　25
構(gòu)建工程的目標　26
構(gòu)建工程的原則　26
2.1　為什么構(gòu)建工程如此重要　27
2.2　從哪里開始　27
2.3　構(gòu)建工程的核心概念　28
2.3.1　版本ID和標記可執(zhí)行文件　28
2.3.2　不可變的版本ID　28
2.3.3　打上版本標記或者標簽　28
2.3.4　管理編譯依賴　29
2.3.5　獨立構(gòu)建　29
2.4　建立構(gòu)建職能的注意事項　30
2.4.1　推廣獨立構(gòu)建　30
2.4.2　過度工程化構(gòu)建　30
2.4.3　保持正直和誠實　31
2.4.4　隸屬研發(fā)部門引起的利益沖突　32
2.4.5　組織結(jié)構(gòu)的選擇　32
2.5　構(gòu)建工具評估和選擇　33
2.5.1　Apache Ant進入構(gòu)建舞臺　33
2.5.2　Maven　34
2.5.3　Maven與Ant　34
2.5.4　使用Ant生成復雜構(gòu)建　34
2.5.5　持續(xù)集成　35
2.5.6　持續(xù)集成系統(tǒng)　35
2.5.7　集成開發(fā)環(huán)境　36
2.5.8　靜態(tài)代碼分析　36
2.5.9　構(gòu)建框架　36
2.5.10　構(gòu)建工具的選擇　36
2.5.11　對比優(yōu)缺點達成一致　37
2.6　質(zhì)量和培訓成本　37
2.7　把構(gòu)建做得更好　37
2.7.1　鮑勃的構(gòu)建秘方　38
2.7.2　測試驅(qū)動的構(gòu)建　38
2.7.3　信任但仍要核查　38
2.7.4　飛機的駕駛艙　38
2.8　構(gòu)建工程師的角色　39
2.8.1　了解構(gòu)建的項目　39
2.8.2　與開發(fā)人員合作　40
2.8.3　招募新人　40
2.9　架構(gòu)是構(gòu)建的基礎(chǔ)　40
2.10　建立構(gòu)建過程　41
2.11　持續(xù)集成與每日構(gòu)建　41
2.12　構(gòu)建工程的前景　42
結(jié)論　42

第3章　環(huán)境配置　43
環(huán)境配置控制的目標　44
環(huán)境配置控制的原則　44
3.1　為什么環(huán)境配置如此重要　45
3.2　從哪里著手　45
3.3　支持代碼提升　45
3.4　管理配置　46
3.4.1　使用的是哪個數(shù)據(jù)庫　46
3.4.2　那筆交易發(fā)生了嗎　46
3.4.3　少用幾個符號　47
3.4.4　集中分配環(huán)境變量　48
3.5　建立配置管理數(shù)據(jù)庫的實際方法　48
3.5.1　識別和控制　48
3.5.2　理解環(huán)境配置　49
3.6　依賴于環(huán)境配置的變更控制　49
3.7　減少控制　49
3.8　管理環(huán)境　50
3.9　環(huán)境配置的未來　50
結(jié)論　51

第4章　變更控制　53
變更控制的目標　54
變更控制的原則　54
4.1　變更控制為何如此重要　54
4.2　變更控制從何做起　55
4.3　變更控制的七種類型　55
4.3.1　優(yōu)先級　55
4.3.2　把關(guān)控制　56
4.3.3　配置控制　56
4.3.4　變更咨詢委員會　57
4.3.5　緊急變更控制　57
4.3.6　過程工程　57
4.3.7　高級管理人員監(jiān)督　57
4.4　建立變更控制　58
4.5　變更控制實例　58
4.5.1　29分鐘變更控制會議　59
4.5.2　投資銀行變更控制　59
4.5.3　貿(mào)易公司的變更控制　60
4.5.4　偽造批準　61
4.6　時刻不要忘記風險　61
4.7　通過變更控制推動配置管理流程　62
4.8　進入/退出標準　62
4.9　事后審查　63
4.10　自我評估　63
結(jié)論　64

第5章　發(fā)布管理　65
發(fā)布管理的目標　66
發(fā)布管理的原則　66
5.1　為什么發(fā)布管理如此重要　66
5.2　從哪里開始　67
5.3　發(fā)布管理的概念和實踐　67
5.3.1　可行的打包策略　67
5.3.2　發(fā)布包版本識別　68
5.3.3　發(fā)布版本的材料清單　68
5.3.4　不可變ID意味著什么　68
5.4　發(fā)布管理人類工程學　68
5.4.1　避免人為錯誤　69
5.4.2　了解技術(shù)　69
5.4.3　構(gòu)建工程工具　69
5.4.4　避免人為錯誤　70
5.4.5　三步走　70
5.4.6　太多可變部分　70
5.5　發(fā)布管理的協(xié)調(diào)職能　71
5.5.1　溝通發(fā)布狀態(tài)　71
5.5.2　不要忘記發(fā)布日程表　71
5.5.3　發(fā)布管理和配置控制　71
5.6　需求跟蹤　71
5.7　將發(fā)布管理提升到新的層次　72
5.7.1　使用加密技術(shù)簽名代碼　72
5.7.2　操作系統(tǒng)對發(fā)布管理的支持　72
5.7.3　改善你的發(fā)布管理過程　73
結(jié)論　73

第6章　部署　75
部署的目標　76
部署的原則　76
6.1　為什么部署很重要　76
6.2　從哪里開始　77
6.3　實踐和實例　77
6.3.1　發(fā)布中轉(zhuǎn)區(qū)　77
6.3.2　腳本控制發(fā)布過程　78
6.3.3　部署框架　78
6.3.4　如果鮑勃犯了個錯誤怎么辦　79
6.3.5　細說存儲庫　79
6.3.6　審計發(fā)行版本　79
6.4　進行配置審計　80
6.5　不要忘記冒煙測試　80
6.6　小失誤導致大問題　81
6.7　溝通計劃　81
6.8　部署應(yīng)當授權(quán)　82
6.9　信任也要核查　82
6.10　改進部署過程　82
結(jié)論　82

第Ⅱ部分　架構(gòu)和硬件配置管理　83

第7章　為配置管理設(shè)計應(yīng)用程序架構(gòu)　85
為配置管理設(shè)計應(yīng)用程序架構(gòu)的目標　86
7.1　為什么架構(gòu)很重要　86
7.2　從哪里開始　87
7.3　配置管理如何促進良好的架構(gòu)　87
7.4　架構(gòu)師可以從測試人員那里學到什么　87
7.5　配置管理驅(qū)動開發(fā)　88
7.6　應(yīng)對不斷變化的架構(gòu)　89
7.7　使用源代碼管理促進架構(gòu)　89
7.8　培訓是關(guān)鍵　89
7.9　作為服務(wù)的源代碼管理　90
7.10　作為服務(wù)的構(gòu)建工程　90
結(jié)論　90

第8章　硬件配置管理　91
硬件配置管理的目標　92
8.1　為什么硬件配置管理的重要　92
8.2　從哪里開始　92
8.3　當無法版本控制電路芯片時　93
8.3.1　配置項的任何其他名稱　93
8.3.2　設(shè)計規(guī)范的版本控制　93
8.4　不要忘記接口　93
8.5　了解依賴關(guān)系　94
8.6　可追溯性　94
8.7　部署變更到固件　94
8.8　硬件配置管理的未來　94
結(jié)論　95

第Ⅲ部分　配置管理中人的因素　97

第9章　合理精簡過程　99
合理精簡配置管理過程的目標　100
9.1　為什么合理精簡配置管理過程很重要　101
9.2　從哪里開始　101
9.3　繁瑣的過程只會成為障礙　102
9.4　軟件過程改進網(wǎng)絡(luò)和推廣能力成熟度模型　102
9.5　正在消失的煩瑣過程　103
9.5.1　敏捷開發(fā)過程就是有用　103
9.5.2　開放統(tǒng)一過程　104
9.5.3　變得精益　104
9.5.4　希望能夠激勵人仔細了解精益軟件開發(fā)的一個非常簡短的描述　104
9.6　過程太少的危險　105
9.7　恰好夠用的過程改進　105
9.8　不要過度工程化配置管理　105
9.9　不要忘了技術(shù)　106
9.10　測試自己的過程　106
9.11　過程咨詢　106
9.12　創(chuàng)建一個可持續(xù)發(fā)展的結(jié)構(gòu)　107
結(jié)論　107

第10章　克服變革的阻力　109
克服變革阻力的目的　110
10.1　為什么克服變革阻力很重要　111
10.2　從哪里開始　111
10.3　過程與企業(yè)文化相匹配　111
10.4　心理學和計算機程序設(shè)計相結(jié)合　112
10.5　從內(nèi)部進行過程改進　113
10.6　選擇首先要解決的問題　114
10.7　培養(yǎng)團隊協(xié)作　114
10.8　為什么優(yōu)秀的開發(fā)人員反對過程改進　115
10.9　程序公正　115
10.10　聽取每個人的意見　115
10.11　展現(xiàn)領(lǐng)導能力　116
10.12　實施過程改進的人本身可能會成為問題　116
10.13　過程和技術(shù)培訓相結(jié)合　116
10.14　傾聽節(jié)奏　117
10.15　過程需要得到測試　118
10.16　嬰兒般的步伐和過程改進　119
10.17　推銷過程改進　119
10.18　什么是我需要的　119
10.19　作為服務(wù)的過程改進　120
10.20　過程改進的游擊戰(zhàn)術(shù)　120
結(jié)論　121

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

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

第Ⅳ部分　合規(guī)、行業(yè)標準和框架　149

第13章　建立IT控制及合規(guī)性　151
建立IT控制及合規(guī)性的目標　152
13.1　為什么IT控制及合規(guī)性很重要　153
13.2　建立IT控制及合規(guī)性的第一步　153
13.3　理解IT控制及合規(guī)性　154
13.3.1　2002年發(fā)布的“薩班斯-奧克斯利法案”　154
13.3.2　內(nèi)部控制的管理評估　154
13.3.3　發(fā)起機構(gòu)委員會　155
13.3.4　用于IT控制框架的COBIT　155
13.3.5　核實并匯報管理層所做出的評估　155
13.3.6　1996年發(fā)布的健康保險隱私及責任法案　156
13.3.7　當美國審計署來敲你門的時候　156
13.3.8　審計結(jié)果　157
13.3.9　美國審計署關(guān)于國家檔案記錄管理局的配置管理實踐的報告　158
13.3.10　美國電子文件檔案館的配置管理規(guī)劃　158
13.3.11　有待改善的領(lǐng)域　159
13.3.12　了解審計結(jié)果　159
13.3.13　美國金融管理局　159
13.4　必不可少的合規(guī)性要求　160
13.4.1　為版本發(fā)布提供可追溯的需求　160
13.4.2　控制生產(chǎn)分離　160
13.5　支持配置管理最佳實踐的道德觀點　161
13.6　通過合規(guī)性來提高工作質(zhì)量和效率　161
13.7　進行配置管理評估　162
13.7.1　評估的第一步　162
13.7.2　無論出現(xiàn)多么糟糕的情況也要先留心去聽　163
結(jié)論　164

第14章　行業(yè)標準和框架　165
使用行業(yè)標準和框架的目標　166
14.1　為什么標準和框架很重要　166
14.2　以IT控制及合規(guī)性為最佳實踐的第一步　166
14.3　必知的專業(yè)術(shù)語　167
14.3.1　配置項　167
14.3.2　配置標識　167
14.3.3　配置控制　168
14.3.4　接口控制　168
14.3.5　配置狀態(tài)統(tǒng)計　168
14.3.6　配置審計　169
14.3.7　分包商/供應(yīng)商的管理手段　169
14.3.8　符合規(guī)范與違規(guī)　170
14.4　將這些條款應(yīng)用在標準和框架里　170
14.5　行業(yè)標準　170
14.5.1　IEEE 828——標準軟件配置管理方案　171
14.5.2　ISO 10007質(zhì)量管理體系——配置管理的指導方針　172
14.5.3　ANSI/ITAA EIA-649-A——配置管理的國家統(tǒng)一標準　172
14.5.4　ISO/IEC/IEEE 12207和15288標準　173
14.6　行業(yè)框架　173
14.6.1　ISACA COBIT　173
14.6.2　能力成熟度模型/能力成熟度模型集成　182
14.6.3　itSMF的ITIL框架　183
14.6.4　軟件工程知識體系　189
14.6.5　開放統(tǒng)一過程(OpenUP)　190
14.6.6　敏捷/SCRUM　190
結(jié)論　191