1、標識需要進行存儲的工件（Artifact）并保障安全存儲；
2、控制并且審計（Audit）對于工件的修改；
3、設立并管理基線（Baseline）；
4、記錄并跟蹤變更請求；
5、維護穩(wěn)定、一致的工作空間；
6、支持對于工件和控件的并發(fā)修改；
7、盡早集成、持續(xù)集成；
8、保證軟件構建的重現(xiàn)能力；
9、以控件（Component）為單位實施版本控制；
10、使用“活動”（Activity）來組織和整合版本集。
下文將介紹前5條最佳實踐。
1、標識需要進行存儲的工件（Artifact）并保障安全存儲
在軟件開發(fā)過程中，我們會得到各種各樣的產(chǎn)出，比如各種文檔、模型、源代碼以及測試腳本等，我們把這些大家勞動的成果統(tǒng)稱為工件（Artifact）。對于一個軟件開發(fā)組織來說，這些工件就構成了組織的核心資產(chǎn)。對于如現(xiàn)金、有價證券之類的資產(chǎn)，我們都會準備一個保險箱，好好地保存；對于軟件資產(chǎn)，我們也需要相似的措施。所以，軟件配置管理工作的第一步就是建立一個安全、可靠的存儲庫（Repository），用于保存組織的核心軟件資產(chǎn)。
這個庫對于開發(fā)團隊來說，就像是財務室里的保險箱。因此，容錯能力和高可靠性是這個庫最重要的屬性。除此之外，隨著組織的增長，置于庫中的數(shù)據(jù)會越來越多，為保證運行效率，庫的可擴展性也是非常重要的一個屬性。
對于存儲庫來說，良好規(guī)劃的備份和災難恢復過程是必不可少的。令人驚訝的是，很多軟件組織在這方面都沒有給予必要的重視，因而也給組織的發(fā)展留下了嚴重的隱患，一旦災難發(fā)生，后果不堪設想。
在建立好存儲庫以后，需要做的工作就是確定將哪些工件置于庫中。根據(jù)實際需要，組織可能會決定只將正式文檔、模型文件、源代碼、發(fā)布版本等文件放入庫中，而對于臨時文檔、編譯時產(chǎn)生的中間文件等，則不將它們放入庫中。我們把放入庫中的文件稱之為配置項（Configuration Item）。
2、控制并且審計（Audit）對于工件的修改
在標識相關的工件并將它們置于存儲庫中以后，我們需要建立對于這些工件的修改控制機制以及審計機制。
庫里的工件不是誰想修改就可以修改的。控制機制必須保證只有拿到授權的人員才能對相關工件進行修改，而審計機制則保證修改的動作被完整地記錄，也就是說，誰修改了這個工件，什么時候做的修改，為什么原因做出這個改動，以及修改了哪些地方（Who、When、Why、What）。
審計機制通常通過“檢出/檢入”（Check out/Check in）模式得到實現(xiàn)。在這種模式下，工件一旦入庫，讀寫權限就變成只讀（read only），如果要對該工件進行修改，則需要通過“檢出”這個步驟；在修改結束以后，如果希望將修改的成果入庫，則需要通過“檢入”這個步驟。在經(jīng)過一次“檢出/檢入”步驟以后，會形成該工件新的版本，因此也有人把上邊的過程稱之為“版本控制”（Version Control）。在版本控制過程中，如果利用一些配置管理工具（或者版本控制工具）的支持，則可以自動地記錄審計工作所需的四個“W”（Who、When、Why、What）。
3、設立并管理基線
通過審計機制我們可以保存一個工件完整的變更歷史；但是一個項目通常是由成百上千個工件構成的，每個工件在變更過程中都會形成一系列的版本，如何確認系統(tǒng)在某個時刻分別由哪些工件的哪些版本構成？這就需要引入一個概念：配置（Configuration）。對于軟件系統(tǒng)來說，在開發(fā)過程中某個時刻存儲庫中所有工件的一個“快照”（snapshot），就形成一個“配置”。對于一些重要時刻的系統(tǒng)配置，我們可以使用基線（Baseline）來進行標志。
IEEE對于基線的定義是：已經(jīng)通過正式復審和批準的某規(guī)約或產(chǎn)品，它因此可以作為進一步開發(fā)的基礎，并且只能通過正式的變更控制過程進行改變.簡單地說，基線就是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨后的工作基于這個標準進行，并且只有經(jīng)過授權后才能變更這個標準。建立一個初始基線后，以后每次對它進行的變更都將記錄為一個差值，直到建成下一個基線。
建立基線的主要原因是：重現(xiàn)能力、可追蹤性和報告能力。
重現(xiàn)能力是指返回并重新生成軟件系統(tǒng)給定發(fā)布版本的能力?？勺粉櫺越㈨椖扛鞣N類型工件（需求、設計、實現(xiàn)、測試等）之間的橫行依賴關系，其目的在于確保設計滿足需求、代碼實施設計以及使用正確代碼編譯生成可執(zhí)行文件。報告能力來源于一個基線內(nèi)容同另一個基線內(nèi)容的比較，基線比較有助于程序調(diào)試并生成發(fā)布說明（Release notes）。
建立基線有以下幾個好處：
(1) 基線為開發(fā)工件提供了一個定點和快照。新項目可以從基線提供的定點之中建立。
(2) 當認為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法。
(3) 可以利用基線重新建立基于某個特定發(fā)布版本的配置，這樣也可以重現(xiàn)被報告的錯誤。
在開發(fā)過程中，需要定期建立基線以確保團隊開發(fā)人員的工作保持同步，通常，在項目生命周期中的里程碑處定期建立基線。
4、記錄并跟蹤變更請求
以上我們談論的都是對于工件的變更活動的實施，下面我們要談到的是軟件配置管理的另一個方面：對于變更請求的管理。這是變更活動的源頭。
著名的軟件大師Brooks曾經(jīng)談到導致軟件開發(fā)困難的一個原因就是軟件的可變性。大家都知道，各種要素，如市場的變化、技術的進步、客戶對于項目認識的深入等等，都可能導致軟件開發(fā)過程中的變更請求的提出，而且承認這種變更請求的合理性也已經(jīng)是工業(yè)界的共識。
但是，如果缺乏對于變更請求的有效的管理能力，紛至沓來的變更就會成為開發(fā)團隊的噩夢。缺乏有效的變更請求管理會導致以下一些問題：
（1） 軟件產(chǎn)品質量低下，對一些缺陷的修正被遺漏；
（2） 項目經(jīng)理不了解開發(fā)人員的工作進展，缺乏對項目現(xiàn)狀進行客觀評估的能力；
（3） 開發(fā)人員不了解手頭工作的優(yōu)先級別，可能出現(xiàn)將緊急的事情放在一邊、而工作在一般優(yōu)先級任務上的情況。
變更請求管理的復雜程度與變更的具體類型有關。簡單地說，變更請求管理會涉及到變更請求的提交、變更請求的復審、變更任務分配、變更結果的驗證等一系列活動。通常，變更請求管理的流程是：由請求者提交變更請求，變更控制委員會（Change Control Board，CCB）召開CCB復審會議對變更請求進行復審，以確定該請求是否為有效請求。如果是，則基于項目團隊所確定的優(yōu)先級、時間表、資源、變更難度、風險、嚴重性以及其他相關標準，判定對該變更的修改程序，并分配實施變更任務的人力資源和時間資源；變更任務實施人員負責實施該變更；實施結束以后提交驗證人員，由驗證人員負責對變更結果進行驗證，如果變更成功則通知相關人員，否則由變更實施人員返工。
典型的變更請求管理如需求變更管理、缺陷追蹤等。實施有效的變更請求管理有以下好處：
（1） 提高軟件產(chǎn)品質量；
（2） 提高開發(fā)團隊溝通效率；
（3） 幫助項目管理人員對產(chǎn)品狀態(tài)進行客觀的評估。
關于變更請求管理的詳細過程以及相關準則PMT將在相關報告中闡述。
5、維護穩(wěn)定、一致的工作空間
在我們把相關工件納入集中的存儲庫、大家也都遵照“檢出/檢入”的工作模式對工件進行修改以后，下一步的工作就是要為每位開發(fā)人員設定“私有”的工作區(qū)，或者叫做工作空間。 工作空間通常以特定的基線為基礎創(chuàng)建，要求能夠做到為指定的任務方便地取出正確的工作版本建立私有工作空間；開發(fā)人員根據(jù)項目要求在自己的私有空間中對工件進行修改和測試活動，而與其他開發(fā)人員相對保持隔離，也就是說，自己的修改活動不會受到他人的影響，也不會影響到其他開發(fā)人員。但是，在保持隔離的同時，又應該提供相應的機制，當開發(fā)人員希望共享工作成果的時候，能夠很方便地實現(xiàn)共享。
開發(fā)人員日常的開發(fā)工作都是在工作空間里進行的，因此，穩(wěn)定性應該是工作空間首要的特性，只有高度穩(wěn)定的工作空間才能保證開發(fā)人員的工作效率。
