中科永聯高級技術培訓中心（www.itisedu.com）
配置管理(Configuration Management，CM)是通過技術或行政手段對軟體產品及其開發過程和生命周期進行控制、規範的一系列措施。配置管理的目標是記錄軟體產品的演化過程，確保軟體開發者在軟體生命周期中各個階段都能得到精確的產品配置。
配置管理過程是對處於不斷演化、完善過程中的軟體產品的管理過程。其最終目標是實現軟體產品的完整性、一致性、可控性，使產品極大程度地與用戶需求相吻合。它通過控制、記錄、追蹤對軟體的修改和每個修改生成的軟體組成部件來實現對軟體產品的管理功能。
早在七十年代初期加利福利亞大學的Leon Presser教授就撰寫了一篇論文，提出控制變更和配置的概念，之後在1975年，他成立了一家名為SoftTool的公司，開發了自己的配置管理工具：CCC，這也是最早的配置管理工具之一。之後，隨著軟體開發規模的逐漸增大，越來越多的公司和團隊意識到了軟體配置管理的重要性，而相應的軟體配置管理工具也如雨後春筍一般，紛紛湧現，比較有代表性的有：Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System)，這兩種工具對日後的配置管理工具的發展做出了重大的貢獻，目前絕大多數廣泛使用的配置管理工具基本上都是基於這兩者的設計思想和體系架構。
一、配置管理在軟體開發過程和項目管理過程中的作用
隨著軟體系統的日益複雜化和用戶需求、軟體更新的頻繁化，配置管理逐漸成為軟體生命周期中的重要控制過程，在軟體開發過程中扮演著越來越來重要的角色。一個好的配置管理過程能覆蓋軟體開發和維護的各個方面，同時對軟體開過程的巨觀管理，即項目管理，也有重要的支持作用。良好的配置管理能使軟體開發過程有更好的可預測性，使軟體系統具有可重複性，使用戶和主管部門用軟體質量和開發小組有更強的信心。
軟體配置管理的最終目標是管理軟體產品。由於軟體產品是在用戶不斷變化的需求驅動下不斷變化，為了保證對產品有效地進行控制和追蹤，配置管理過程不能僅僅對靜態的、成形的產品進行管理，而必須對動態的、成長的產品進行管理。由此可見，配置管理同軟體開發過程緊密相關。配置管理必須緊扣軟體開發過程的各個環節：管理用戶所提出的需求，監控其實施，確保用戶需求最終落實到產品的各個版本中去，並在產品發行和用戶支持等方面提供幫助，回響用戶新的需求，推動新的開發周期。通過配置管理過程的控制，用戶對軟體產品的需求如同普通產品的訂單一樣，遵循一個嚴格的流程，經過一條受控的生產流水線，最後形成產品，發售給相套用戶。從另一個角度看，在產品開發的不同階段通常有不同的任務，由不同的角色擔當，各個角色職責明確，涇渭分明，但同時又前後銜接，相互協調。
好的配置管理過程有助於規範各個角色的行為，同時又為角色之間的任務傳遞提供無縫的接合，使整個開發團隊象一個交響樂隊一樣和諧而又錯雜地行進。正因為配置管理過程直接連線產品開發過程、開發人員和最終產品，這些都是項目主管人員所關注的重點，因此配置管理系統在軟體項目管理中也起著重要。配置管理過程演化出的控制、報告功能可幫助項目經理更好地了解項目的進度、開發人員的負荷、工作效率和產品質量狀況、交付日期等信息。同時配置管理過程所規範的工作流程和明確的分工有利於管理者應付開發人員流動的困境，使新的成員可以快速實現任務交接，儘量減少因人員流動而造成的損失。
二、配置管理的功能
配置管理系統應該具備以下主要功能：
並行開發支持：因開發和維護的原因，要求能夠實現開發人員同時在同一個軟體模組上工作，同時對同一個代碼部分作不同的修改，即使是跨地域分布的開發團隊也能互不干擾，協同工作，而又不失去控制；
修訂版管理：跟蹤每一個變更的創造者、時間和原因，從而加快問題和缺陷的確定 ；
版本控制：能夠簡單、明確地重現軟體系統的任何一個歷史版本 ；
產品發布管理：管理、計畫軟體的變更，與軟體的發布計畫、預先定製好的生命周期或相關的質量過程保持一致；項目經理能夠隨時清晰地了解項目的狀態 ；
建立管理：基於軟體存儲庫的版本控制功能，實現建立（build）過程自動化 ；
過程控制：貫徹實施開發規範，包括訪問許可權控制、開發規則的實施等 ；
變更請求管理：跟蹤、管理開發過程中出現的缺陷（Defect）、功能增強請求（RFE）或任務（Task），加強溝通和協作，能夠隨時了解變更的狀態 ；
代碼共享：提供良好的存儲和訪問機制，開發人員可以共享各自的開發資源 ；
三、配置管理的流程
圖17-1 配置管理流程圖
1、制定配置管理計畫
配置管理員制定《配置管理計畫》，主要內容包括配置管理軟硬體資源、配置項計畫、基線計畫、交付計畫、備份計畫等。CCB審批該計畫。
2、配置庫管理
配置管理員為項目創建配置庫，並給每個項目成員分配許可權。各項目成員根據自己的許可權操作配置庫。配置管理員定期維護配置庫，例如清楚垃圾檔案、備份配置庫等。
3、版本控制
在項目開發過程中，絕大部分的配置項都要經過多次的修改才能最終確定下來。對配置項的任何修改都將產生新的版本。由於我們不能保證新版本一定比老版本“好”，所以不能拋棄老版本。版本控制的目的是按照一定的規則保存配置項的所有版本，避免發生版本丟失或混淆等現象，並且可以快速準確地查找到配置項的任何版本。
配置項的狀態有三種：“草稿”、“正式發布”和“正在修改”，本規程制定了配置項狀態變遷與版本號的規則。
4、變更控制
在項目開發過程中，配置項發生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被隨意修改而導致混亂。
修改處於“草稿”狀態的配置項不算是“變更”，無需CCB的批准，修改者按照版本控制規則執行即可。
當配置項的狀態成為“正式發布”，或者被“凍結”後，此時任何人都不能隨意修改，必須依據“申請－審批－執行變更－再評審－結束”的規則執行。
5、配置審計
為了保證所有人員（包括項目成員、配置管理員和CCB）都遵守配置管理規範，質量保證人員要定期審計配置管理工作。配置審計是一種“過程質量檢查”活動，是質量保證人員的工作職責之一。
四、配置管理的實施
實施配置管理系統，一般的步驟和需要考慮的問題如下：
規劃、調整網路開發環境
一個規劃良好的開發環境，是實施配置管理系統的前提。在此階段我們要對配置管理系統做出規劃，主要考慮以下問題：
* 網路的頻寬、拓撲結構
*伺服器的選擇、命名規範
*存儲區的定位
*開發人員及組的命名規約等
設計配置管理庫
根據項目開發的要求，設計開發資源的存儲模式，良好的存儲模式有利於減輕管理上的負擔，增強配置管理庫的訪問性能，同時便於控制訪問許可權，保護軟體資產。
定義配置管理系統的角色
在此階段，我們需要確定與配置管理相關的所有角色，包括他們的相應的活動。在開發過程中，一個開發人員可能兼任多種角色，但一項任務在同一時刻只能由一個角色來執行。
一般配置管理中的角色主要包括：
項目經理：項目經理在配置管理方面的職責是依靠配置管理員、系統管理員和系統體系結構設計人員的幫助，制定項目的組織結構和配置管理策略。這些工作包括：定製開發子系統，定製訪問控制，制定常用策略，制定集成里程碑，以及進行系統集成；
配置管理員：配置管理員的職責是根據項目經理制定的開發組織結構和策略，實施、維護配置管理的環境。其主要職責如下：創建配置管理庫，對存儲庫進行日常備份和恢復，維護配置管理環境，及管理配置管理相關的用戶；
軟體開發人員：軟體開發人員依據項目的開發和配置管理策略，創建、修改和測試開發工件；
集成人員：對軟體進行歸併，形成相應的基線或發布版本 ；
QA人員：需要對軟體配置管理有較深的認識，其主要工作是跟蹤當前項目的狀態，測試，報告錯誤，並驗證其修復結果；
制定配置管理流程
這是配置管理實施的一個重要階段，其主要目的是根據項目開發的需要，制定相應的配置管理流程，以更好地支持開發，主要活動包括：
定製並行開發策略：合理的並行開發策略應該具有以下特點：協調項目的複雜性和需求，統一創建分支類型和元數據，為開發過程中的變更集成制定有效的規範，適時反映開發過程中方法和需求的變化
發布版本管理：軟體開發過程中的一個??的階段版本或發布版本，我們一般將其稱為穩定基線。一個穩定基線代表新開發活動的開始，而一系列定製良好的活動之後又會產生一個新的穩定基線。有效地利用此項功能，在項目開發過程中可以自始至終管理、跟蹤工件版本間的關聯。
相關人員的培訓
一般來講，實施配置管理系統，相關人員需要接受以下培訓：
管理員培訓：針對配置管理員，主要學習配置管理工具管理相關內容
開發人員培訓：針對開發人員，主要學習配置管理工具與開發相關的常用操作
管理流程培訓：針對全體人員，目的是了解配置管理策略和流程，以及如何與開發管理、項目管理相結合
五、配置管理經驗談
圍繞配置管理,世界一些致力於軟體工程研究的公司在深入理解ISO 9000的基礎上, 推出了各種符合ISO 9000配置管理標準的工具軟體,如INTERSOLV公司的PVCS,Rational公司的Clear Case等。這些配置管理工具面向軟體規範化、工程化、自動化的需要,幫助開發團隊提高科學管理水平,從而提高工程效率,降低工程成本。現以PVCS為例,結合我們的實際經驗,談談我們實施配置管理的益處:
1. 節約費用
(1) 縮短開發周期
利用PVCS的Version Manager對程式資源進行版本管理和跟蹤,建立公司的代碼知識庫,保存開發過程中每一過程版本,這樣大大提高了代碼的重用率,還便於同時維護多個版本和進行新版本的開發,防止系統崩潰,最大限度地共享代碼。同時項目管理人員可以通過Version Manager查看項目開發日誌,測試人員可以根據開發日誌和不同版本對軟體進行測試,工程人員可以從Version Manager上得到不同的運行版本,並且Version Manager 可以安裝在Web Server供外地施工人員存取最新版本,無需開發人員親臨現場。
利用Tracker組建開發團體之間的問題跟蹤及訊息通迅,通過其Notify模組與電子郵件結合起來大大加強了開發團體之間的溝通,Reporter模組可對發現的問題進行整理、以報表方式分類報出,作為開發的指導。
以上為PVCS的兩個主要模組,科學地套用可以大大提高開發效率,避免了代碼覆蓋、溝通不夠、開發無序的混亂局面,如果利用了公司原有的知識庫,則更能提高工作效率,縮短開發周期。
(2) 減少施工費用
利用PVCS進行軟體配置管理後,建立開發管理規範,把版本管理檔案掛接在公司內部的Web伺服器上,內部直接通過Netscape訪問Version Manager,工程人員通過遠程進入內部網,獲取所需的最新版本。開發人員無需下現場,現場工程人員通過對方系統管理員收集反饋意見,書面提交到公司內部開發組項目經理,開發組內部討論決定是否修改,並作出書面答覆。這樣做,可以同時回響多個項目點,防止開發人員分配到各個項目點、分散力量、人員不夠的毛病,同時節約大量的旅差費用。
2. 有利於知識庫的建立
(1) 代碼對象庫
軟體代碼是軟體開發人員腦力勞動的結晶,也是軟體公司的寶貴財富,長期開發過程中形成的各種代碼對象就像一個個零件坯一樣,是快速生成系統的組成部分。長期的一個事實是:一旦某個開發人員離開工作崗位,其原來所作的代碼便基本成為垃圾,無人過問。究其原因,就是沒有專門對各人的有用對象進行管理,把其使用範圍擴大到公司一級,進行規範化,加以說明和普及。Version Manager為對象管理提供了一個平台和倉庫,有利於建立公司級的代碼對象庫。
(2) 業務及經驗庫
通過PVCS Version Manager的注釋及Tracker,可形成完整的開發日誌及問題集合,以文字方式伴隨開發的整個過程,不依某個人的轉移而消失,有利於公司積累業務經驗,無論對版本整改或版本升級,都具有重要的指導作用。
3. 規範管理
(1) 量化工作量考核
傳統的開發管理中,工作量一直是難以估量的指標,靠開發人員自已把握,隨意性相當大;靠管理人員把握,主觀性又太強。採用PVCS管理後,開發人員每天下班前對修改的檔案 Check In,其中記述當天修改細節描述,這些描述可以作為工作量的衡量指標。
(2) 規範測試
採用PVCS以後,測試有了實實在在的工作,測試工作人員根據每天的修改細節描述對每一天的工作做具體的測試,對測試人員也具有可考核性,這樣環環相扣,大大減少了其工作的隨意性。
(3) 加強協調與溝通
採用PVCS後,通過Version Manager文檔共享及其特定鎖機制、Tracker與電子郵件的集成,大大加強了項目成員之間的溝通,做到有問題及時發現、及時修改、及時通知,但又不額外增加很多的工作量。
六、配置管理的精髓
具體來講，配置管理包含如下內容：
¾ 標識：識別產品的結構、產品的構件及其類型，為其分配唯一的標識符，並以某種形式提供對它們的存取。
¾ 控制：通過一定的機制控制對配置項的修改
¾ 狀態報告：記錄並報告配置項以及元數據的狀態。
¾ 配置審計：確認產品的完整性並維護配置項間的一致性。
從上面的描述，我們知道，配置管理的基本單位是配置項。
從“哲學”意義上講，它記錄配置項的三個方面：
¾ 從哪裡來？此項可歸結為WWW的問題，（Who）誰創建的？（When）什麼時間創建的？（Why）為什麼創建此配置項？
¾ 當前在哪裡？此項紀錄配置項當前的存儲位置以及狀態。
¾ 將到哪裡去？通過配置ONT>
配置項可以是大粒度的，也可以是小粒度的。如果跟蹤個別需求，那么不必要把整個需求規格說明文檔定義為一個配置項，可以把每個需求定義為配置項；如果把軟體開發工具也放入配置管理系統，那么把配置項定義為檔案級就不合適了，只需要跟蹤開發工具的版本，即把整個配置工具定義為一個配置項就足夠了。
簡而言之，配置項可以是檔案級粒度的，也可以使檔案版本級粒度的。當然，粒度越小管理的成本越高，但是配置的精度也就越高。
一個完整的SCM系統要具有三個核心功能：版本控制、變更控制、配置控制以及兩個支持功能：狀態統計和配置審計。
版本控制
版本，亦稱配置標識，是指某一特定對象的具體實例的潛在存在。這裡的某一特定對象是指版本維護工具管理的軟體組成單元，一般是指源檔案；具體實例則是指軟體開發人員從軟體庫中恢復出來的某軟體組成單元的具有一定內容和屬性的一個真實拷貝。例如，對源檔案的每一次修改都生成一個新版本。
版本控制就是對在軟體開發過程中所創建的配置對象的不同版本進行管理，保證任何時候都能取到正確的版本以及版本的組合。
變更控制
變更控制是通過對變更請求（Change Request，簡稱CR）進行分類、追蹤和管理的過程來實現的。
變更的起源有兩種：功能變更和缺陷修補（Bug-Fix）。功能變更是為了增加或者刪除某些功能。缺陷修補則是對已存在的缺陷進行修補。
對變更進行控制的機構稱為變更控制委員會（Change Control Board，簡稱CCB）。變更控制委員會要定期召開會議，對近期所產生的變更請求進行分析、整理，並做出決定。而且要遵循一定的變更機制。
下面是一個典型的變更機制：
我們可以隨著變更過程的推進，提升配置項的狀態。 這方面的工具有Bugzilla。
配置控制
配置控制使用戶能夠通過對適當版本的選擇來組成特定屬性（配置）的軟體系統，這種靈活的“組裝”策略使得配置管理系統象搭積木似的使用已有的積木（版本）組裝成各種各樣、不同功能的模型。
軟體產品的每個版本都是一組配置項（原始碼、文檔、數據）的集合。配置控制就是要保證每個配置的完整性和精確性。
舉個例子來說，我們要發布軟體的32.6版本，那么我們就要把原始碼、文檔、數據中所有這個應該包含到這個版本中的正確配置項檢出。
在開發過程中，我們在不同階段要建立各種基線。基線的建立是配置控制功能的典型套用。所以說，基線是具有里程碑意義的一個配置。
一般的商業軟體配置管理工具都具有配置控制的功能，只是靈活性和精確性有差別。
狀態報告
狀態報告要回答所謂4W的問題：
What：發生了什麼事？
Who：誰做的此事？
When：此事是什麼時候發生的？
Why：為什麼做此事？
狀態報告還要能夠報告所有配置項以及變更請求的狀態。
配置審計
配置審計要審查整個配置管理過程是否符合規範，配置項是否與需求一致，記錄正確，配置的組成是否具有一致性等等。
由於現在軟體行業越來越重視質量，許多項目專門成立質量保證部門專門來進行配置審計。所以現在也可以說，配置審計是一個SQA（軟體質量保證）活動。
配置管理的商業模型
配置管理的實施包括兩部分：工具和規範。
在軟體開發過程自動化的今天，沒有工具的支持而實施配置完整的配置管理是不能想像的。因此選擇一個符合公司或項目的工具至關重要。在配置管理系統中，我們可歸納出四種模型。當前商業工具一般採用其中一種或幾種模型。
我們通過對商業模型的理解可以幫助我們了解某種工具是否適合我們公司或項目。
Cico模型
CICO模型主要關注的是單個檔案的版本控制。圖顯示了一個支持CICO模型的cm系統的工作過程。用戶利用庫和檔案系統來進行工作。檔案被版本化並存儲到庫中，新版本的產生是由庫工具控制的。然而， 檔案在庫中不是可以直接存取的，用戶必須去檢出（即Check Out）一個檔案的版本到工作空間中以便讀取它的內容。更改後的檔案可以被檢入庫中（即Check in）,產生檔案的一個新版本。
此模型的代表工具是SCCS和CVS。
組織模型
組織模型由CICO模型自然導出，建立於構件版本圖的基礎之上，同時依賴於存儲庫和工作空間的概念，可以通過對構件加鎖進行並發控制。組織模型的重點是在CM系統支撐下加強了對創建配置、對有關的歷史信息的管理和使用他們作為工作環境的支持。
組織模型中的配置由系統模型和版本選擇規則組成。系統模型列出了組成系統的所有的構件。版本選擇規則指出了組成配置的每一個構件選擇版本。選擇規則用於系統模型，選擇構件版本，即綁定一構件到某一版本。這個模型的操作方式是：開發員根據模型的構件定義整個系統，並在每一步驟中給每個構件選擇合適的版本。版本操作的工作方式如圖所示。
CM支持主要關心的是維護系統和其構件的版本歷史，並選擇符合一致性配置的構件版本。只有在所選構件的版本與所選其它構件版本一致時才認為一個配置版本。
此模型的代表工具是CCC。
長事務模型
長事務模型主要支持包括一系列原子變更的全系統演變和由團隊開發員對系統變更的協調。開發員主要操作配置而非單獨的構件。事務提交的結果是新配置版本，一系列連續的變更結果生成一系列的配置版本，稱為開發路徑。
在長事務模型中，開發員主要的工作對象時配置，開發員首先選擇系統配置版本，接下來把關注重點放在系統結構上。構件的版本由配置隱式決定。長事務由兩個概念組成：工作空間和並發控制方案。工作空間來源於存儲庫或一個封閉工作空間中的一個固定配置。工作空間由工作配置和一系列已保存的配置組成。工作配置代表構件和系統結構能夠被動態更改的配置。提供通過工作空間進行的透明庫訪問、將高效的庫存儲技術套用於工作空間和管理派生構件的版本。
此模型的代表系統是NSE。
變更集模型
主要集中於對系統配置的邏輯變更的支持。在這個模型中引入的變更集表示組成邏輯變更的對不同構件修改的集合，它是創建變更的活動完成後對邏輯變更的記錄。支持這個模型的CM系統用戶可以直接操作變更集。在變更集模型中，配置可描述為由基線和一組變更集組成。
變更傳播給其它配置可通過包含各自變更集來進行。開發員使用不同的集成策略將邏輯變更集包含到一個新的系統發行中。這樣的好處非常明顯，例如，我們現在維護10個不同版本的產品，現在要對所有的版本修改一個缺陷（Bug）。如果相同的工具簡單的重複10次顯然是不可接受的。而通過變更集把這個邏輯變更從一個版本自由的傳到另外一個版本。
開發員可跟蹤邏輯變更和確定這些變更是否屬於特定配置。這種配置管理的方法，因為其將重點放於邏輯變更上，所以被稱作面向變更的配置管理。它不同於現在的其他3種CM模型，因為其它3種CM模型使用的面向版本的方法把重點放在構件和配置版本上。
在單一構件的情況下，變更集是兩個檔案版本之間區別的集合，通常指的是增量內容。對配置來說，變更集就是兩個配置版本之間區別的集合。這組區別就是兩個配置版本間的修改構件增量集合，即變更構件集的增量。
面向變更的觀點不同於面向版本的觀點。這有兩點不同，一是邏輯變更的顯式表示允許對與單個構件和配置有關的變更集進行跟蹤。二是引用單個變更集並有選擇地將它們納入配置管理中的這種能力提供了對系統演化管理的支持，這種演化是基於將邏輯變更傳播到維護的系統配置進行的。
此模型的代表工具是UCM和SABLIME。
結束語
配置管理本身無論從理論和實踐都在不斷豐富和發展。例如，配置管理套用於“知識庫”的管理就產生了“內容管理”這一新的領域。配置管理提供的狀態報告和數據統計也為軟體度量提供了決策依據。配置管理為項目管理提供了各種監控項目進展的視角，為項目經理確切掌握項目進程提供了保證。配置管理也為開發人員提供了一個協作的平台，在此平台上，大家能夠更有效率的交流和協作。可以說，配置管理是軟體開發的基石！
配置管理近年來在中國得到了極大的認可，可以毫不誇張的說，沒有配置管理，就談不上軟體開發，就談不上軟體質量，就談不上軟體業的發展。隨著軟體業規模的擴大，配置管理的實施不是要不要的問題，而是什麼時間、如何實施的問題了。
參考文獻：
Babich, W.A., Software Configuration Management, Addison-Wesley, 1986.
Peter H. Feiler, Configuration Management Models in Commercial Environment, CMU/SEI-91-TR-7, 1991.4
