【原創】9.9專案管理MSN群主題：如何開展配置管理--工具和方法

提問：什麼是配置管理

穀雨霖【pharos】-CTO-BJ 說:
先問個問題，大家認為什麼是配置管理？
李倩 說:
配置管理至少包括版本管理？
echo-PM-西安 說:
版本的控制
太陽：平衡！高效！成長！雙贏！ 說:
包括所有資源的管理
鏡子-教師-廣州 說:
對軟體開發過程的各類程式\文件分類進行歸檔\跟蹤\入庫\控制變更

講解：配置管理解決八大問題

穀雨霖【pharos】-CTO-BJ 說:
在CMMI和IEEE關於配置管理的正式定義是：軟體配置管理是軟體工程中的一項規程，包括相關工具和應用技術（過程或方法），公司用它來管理軟體資產變更。
什麼意思呢？
配置管理，主要目的是進行工作產品管理，其中包括各類文件、程式碼、版本、紀要、bug等等
但大家通常會簡單認為，配置管理就是版本管理
缺乏配置管理會有哪些問題
1、組織的知識和過程財富流失
現代的社會競爭激烈，人員流動頻繁，如果由於沒有必要的配置管理流程和工具，大量的文件和程式碼等知識財富必然缺乏統一的管理，可能隨意地儲存在專案經理和軟體工程師各

自的機器裡，往往會因為硬碟的故障或人員的離職而永遠的消失，軟體組織的數字財富就這樣因為缺乏必要的配置管理而白白的流失。
2、不能及時瞭解專案的進展狀況
現代軟體工程思想認為越早發現缺陷和風險，採取相應措施的代價越小。CMM 的一個重要作用就是要提高軟體開發過程中的可視性，使得問題能夠被及時的發現。然而由於缺乏配

置管理的流程和工具的支援，部門主管無法確切得知專案的進展情況，即便是專案經理也不知道各個開發人員的具體工作，專案進展隨意性很大。所有的問題往往都會集中到專案

里程碑時一起出現，這必然會造成巨大的開銷，其結果往往是容忍部分缺陷存在或者延誤開發週期。所有問題只能寄希望於最終實施時再解決，專案的實施工作因此變成了無法匯

報、無法理清、無休止的維護。
3、缺乏實現並行開發的手段
在日常的開發工作中，經常會出現並行開發的需求，比如：對於一個專案可能要在開發新版本的同時繼續對先前的版本進行必要的維護，或者針對某個特定的版本需要針對不同的

客戶同時進行客戶化的修改等等。在並行模式下，不同開發人員可以同時編輯修改某一檔案，並行開發有可能產生衝突，但是卻能夠提高開發效率。如果沒有配置管理工具的支援

，進行並行開發將十分困難，單單通過人工操作，往往會造成修改過的bug 重複出現或者幾個人進行相同的工作，產生不必要的浪費。
4、軟體複用率低下
軟體複用是現代軟體工程中的重要思想，是提高軟體產品生產效率和質量的重要手段。軟體產品是一個公司的寶貴財富，程式碼的可重用性是相當高的，如何建好知識庫，用好知識

庫將對公司優質高效開發產品產生重大的影響。但如果沒有良好的配置管理流程，軟體複用的效率將大打折扣，比如對於複用的程式碼進行了必要的修改或改進，卻只能通過手工的

方式將發生的變更傳遞給所有複用該軟體的專案，效率如何可想而知。另外由於缺乏進行溝通的必要手段，各個開發人員各自為政，編寫的程式碼不僅風格迥異，而且編碼和設計脫

節，往往會導致開發大量重複的難以維護的程式碼。
5、無法開展規範化的測試工作
在傳統的開發方式中，由於缺乏必要的配置管理和變更控制，測試工作只是人們的一種主觀願望，根本無法提出具體的測試要求，加之開發人員的遮醜，測試工作往往是走走過場

，測試結果既無法考核又無法量化，當然就無法對以後的開發工作起指導作用。
6、對軟體版本的釋出缺乏有效的管理
因為缺乏有效的管理手段，往往會在產品釋出時卻無法確定該版本所有的元件，或者向使用者提供了錯誤的版本。對於特定客戶出現的問題，無法重現其使用的版本，只能到使用者的

現場才能進行相應的除錯工作。由於應用軟體的特點，各個不同的客戶會有不同的要求，開發人員要手工地保持多份不同的拷貝，即使是相同的問題，但由於在不同 地方提出，由

不同人解決，其做法也不盡相同，程式的可維護性越來越差。這些都會延長實施的週期，同時意味著人力物力的浪費。
可見，版本管理只在第六位。
7、缺乏歷史資料的積累，沒有軟體開發的歷史資料
缺乏軟體開發的歷史資料是大多數軟體專案失敗的關鍵所在，這樣的結論也許使很多人感到吃驚，但事實就是如此。因為軟體開發的歷史資料是反映軟體開發隊伍的能力的標尺，

沒有了這個標尺，就無法對軟體的開發過程有一個清醒的認識。而良好的配置管理正是收集軟體開發歷史資料的重要來源。
8、無法有效的管理和跟蹤變更
軟體的一個顯著特點就是易於改變，沒有配置管理將無法對軟體的變更進行有效的記錄、跟蹤和控制。
這八點做好了，就是一個合格的配置管理過程
1、組織的知識和過程財富流失
2、不能及時瞭解專案的進展狀況
3、缺乏實現並行開發的手段
4、軟體複用率低下
5、無法開展規範化的測試工作
6、對軟體版本的釋出缺乏有效的管理
7、缺乏歷史資料的積累，沒有軟體開發的歷史資料
8、無法有效的管理和跟蹤變更
我要強調的是，要制定好配置管理計劃才能有效開展配置管理
也就是說，以上這8條是公司都非常關注的點，但每個專案的重點是不一樣的
文件程式碼記錄、版本控制以並行開發或回退、變更管理是重中之重

繼續：配置管理三核心

lmeteor_cyy@hotmail.com 說:
我覺得如果把這8點都歸結為配置管理的功勞，感覺有點過了
穀雨霖【pharos】-CTO-BJ 說:
是有點擴大。通常看核心的這三點即可
1、沒有文件記錄、程式碼記錄，我們無法衡量結果是否有效
舉個例子，評審通過的文件要受控，即入庫
評審紀要不受控，如何知道評審時如何開展的，評審質量如何等等
開發計劃要求9.10提交程式碼，配置管理庫看到的是9.12入庫的
那麼，我們怎麼知道是按時提交的程式碼
簡單，9.12就是delay3天，考核依據
2、版本控制以並行開發或回退
版本是很關鍵的。這裡面涉及很多概念
我們做產品不是一蹴而就，中間會出來大量的正式、非正式、補丁版本等等
那麼，在不同的版本上衍生的功能、bug修改如何管理，是否要管理都是配置管理非常看重的點
沒有配置計劃，會產生大量的版本，最後修改bug、合併功能可能是一個非常龐大的事情
掛一漏萬太容易了
3、變更管理
這是配置管理的重點項，就是說一個專案、產品開發過程變化是難免的
但要通過配置管理，將變化前後的東西記錄下來
變更帶來的是範圍變化，範圍變化帶來的是工作量的變化，那麼進度計劃隨之而變。
如果不控制、記錄變更，拿什麼交付給客戶，是否100%，如何考核專案組
從上可見，配置管理要做得好是非常不容易的
通常，從配置管理這裡會分支出來配置工具管理員
即，很多大公司例如IBM、華為有專門的配置工具管理員，來控制程式碼分支、如何拆分、如何合併等等

談配置計劃和配置工具

1、先說配置計劃。
配置計劃，要根據公司具體情況，結合上面提到的內容制定
這個計劃要把配置庫如何建立、配置許可權等等細節給與規定
我可以給大家一個參考：
1. 引言    1
1.1 目的    1
1.2 術語定義    1
1.3 參考資料    1
2. 軟體配置    2
2.1 軟體配置環境    2
2.2 軟體配置項    2
2.3 配置管理員    3
3. 軟體配置管理計劃    4
3.1 建立示例配置庫    4
3.2 配置標識管理    6
3.3 配置庫控制    7
3.4 配置的檢查和評審    8
3.5 配置庫的備份    9
3.6 配置管理計劃的修訂    9
3.7 配置管理計劃附屬文件    9
4. 里程碑    11
附錄1 文件命名規定    12
1、受控配置庫檔案命名規則    12
2、非受控配置庫檔案命名規則    12
3、提交文件檔案命名規則    12
附錄2 文件編碼規範    13
附錄3 帳號及許可權管理    14
附錄4 配置庫使用規定    16
文件修改記錄    17


上面是配置計劃模板的目錄，從中可以指導配置計劃的開展。
其中，名字定義可以包括：
軟體配置管理：簡稱SCM（Software Configuration Management的縮寫），是在專案開發中，標識、控制和管理軟體變更的一種管理。配置管理的使用取決於專案規模和複雜性以

及風險水平。軟體的規模越大，配置管理就顯得越重要。

基線：(BaseLine) 是專案儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨後的工作基於此標準，並且只有經過授權後才能變更這個標準。建立一個初

始基線後，以後每次對其進行的變更都將記錄為一個差值，直到建成下一個基線。

配置管理員：專案組中負責配置管理工作的角色，該角色可以兼職。在某一開發階段通過評審或某一質量檢查點通過稽核後，配置管理員負責統一新增或修改相關文件的最新有效

版本以及審批人簽字。

配置標識：（Configuration Identification）對軟體專案在開發過程中的資源進行標識，以便識別。

配置檢查：（Configuration Audit）對軟體配置管理過程中的行動進行檢查。

配置計劃的核心是配置項的建立
需要配置管理員和PM、產品經理等人明確，例如：
可以在專案的實施過程中，將配置庫分為受控配置庫和非受控配置庫兩種
受控配置庫
在本專案開發實施的整個過程中，根據不同階段的配置管理劃分11個受控配置目錄，只有配置管理員擁有增加和修改的許可權，其它使用者只有只讀的許可權。受控配置庫的目錄為：
00初始配置
01啟動
02需求分析
03設計
04編碼
05測試
06安裝
07總結
08變更
09專案管理
10環境配置

初始配置庫的根目錄中包含XXXX專案的配置檔案清單，該文件包括本專案開發過程中應該提交的文件的清單，在實際開發過程中，根據實際情況，可以在清單中酌情修改、增加和

刪除需要提交的文件。具體內容參見本文3.3的“配置檔案清單的維護”。
各個配置目錄內應該包含的文件，請參見“XXXX專案配置檔案清單.xls”。

非受控配置目錄
在本專案開發過程中，設立了非受控配置目錄。設立非受控配置目錄的目的是為了統一管理和存放開發過程中產生的臨時文件和過程性文件，沒有格式及命名上的嚴格要求，使項

目組成員在思考、設計時不受太多的限制和約束，能夠更有效地發揮個人能力，符合以人為本的原則。
在專案初期，設立了以下三個目錄：
目錄名稱    用途及說明
個人工作區    用於儲存專案成員自己編寫的文件，每個專案成員都有自己獨立的工作目錄
小組工作區    用於儲存小組成員寫作編寫的文件，每個小組都有自己獨立的工作目錄
文件提交區    作為非受控配置庫和受控配置庫之間的緩衝，用於提交已經定稿的文件和程式碼，在評審通過後，再由配置管理員取出並提交到受控配置庫中

其他的就不列了

談第二個問題
配置管理工具
業內通常用的配置管理工具很多
有國產的和外國的，各不相同，功能強大程度也不一樣，要篩選。

支援常見的平臺
Firefly
軟體本身基於Java開發，可在Windows、Linux、Solaris、HP-UX、AIX等常見平臺上使用，平臺之間的移植也非常方便
CVS
支援幾乎所有的作業系統
PVCS
軟體本身基於Java開發，能夠支援常見的平臺
VSS
僅支援Windows作業系統

ClearCase是IBM的，非常細緻龐大的工具，我們在用
Firefly是國內的一家公司
VSS是基本免費的工具
CVS、PVCS、SVN等工具也非常好用

ClearCase
伺服器採用多程式機制，使用自帶多版本檔案系統MVFS，對效能有較大負面影響。做為一款企業級、全面的開發配置管理工具，適用於大型開發團隊

Firefly
伺服器採用了多執行緒的應用伺服器，效能表現優秀，做為一款企業級、全面的開發配置管理，能適用於50人到上千人的團隊

CVS
較高的執行效能，適用於各種級別的開發團隊

PVCS
伺服器採用檔案系統共享方式，對CPU、記憶體及網路要求較高，效能一般，僅適用於中小型專案團隊，不適合於企業級應用

VSS
相對功能單一、簡陋，適用於幾個人的小型團隊，在資料量不大的情況下，效能可以接受

以上是http://space.itpub.net/?uid-12639375-action-viewspace-itemid-156983這篇文章的分析，非常到位

上面是關於配置管理的筆記系統的介紹

討論：

大家交流討論一些細節

1、老谷，你們一般會有多少個資料庫。比如工作庫、受控庫等
一般3個庫，受控、開發、臨時公用庫

2、將程式碼放到ＶＳＳ上怎麼組織呢？　因為我們有框架，框架中有專案。是放在一起呢？還是分開放？
這個是基線和分支的管理模式細節，各走各的版本，在不同的點分支、融合。這個是需要公司系統架構師來協助定計劃的。就是說，國外的配置管理工程師是系統級的，是公司產

品、專案開發的大牛。可以提出自己在產品基線的規劃。
一般的專案不需要分支，只做簡單的管理即可，即文件、程式碼、版本受控。但專案多了，產品多了，平臺是節省費用和降低管理的好方法。

3、專案經理需不需要懂配置管理？
專案經理要懂得配置管理方能較好的管理專案。只要是正規公司必須要配置管理，否則，你今天能找到08.9月的版本，程式碼麼？
淺用，真的很簡單。大家把文件，程式碼傳上去，記得checkout,checkin就行了。
專案經理只要有意識check in文件、程式碼、版本是基本的要求，即沒人力天天做，那麼在專案的階段點集中做下。
否則出問題哭都來不及。還會有配置庫異地備份的問題等等。

4、配置管理人員
在很多中小專案組，配置管理員是兼職的，甚至可以開發、測試分開管理，然後需要QA人員來檢查他們的工作。
大公司配置管理和質量管理，都應有專人任職。版本是一方面，基線是一方面。
配置管理，有時是從專案組內部抽人來管，因為要不斷解決新程式碼、老程式碼、bug fixed等問題

5、甲方如何參與到乙方的配置管理中呢
甲方對配置管理估計不需要太多控制，階段點監察他們的庫足夠了
你們要參與進去，就照你說的這情況，太累。

6、SVN的優勢是？
它可提供B/S,可以在公網上、專網上使用，利於異地開發管控

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-614263/，如需轉載，請註明出處，否則將追究法律責任。