1、標識需要進行存儲的工件（Artifact）并保障安全存儲；

2、控制并且審計（Audit）對于工件的修改；

3、設(shè)立并管理基線（Baseline）；

4、記錄并跟蹤變更請求；

5、維護穩(wěn)定、一致的工作空間；

6、支持對于工件和控件的并發(fā)修改；

7、盡早集成、持續(xù)集成；

8、保證軟件構(gòu)建的重現(xiàn)能力；

9、以控件（Component）為單位實施版本控制；

10、使用“活動”（Activity）來組織和整合版本集。

下文將介紹前5條最佳實踐。

1、標識需要進行存儲的工件（Artifact）并保障安全存儲

在軟件開發(fā)過程中，我們會得到各種各樣的產(chǎn)出，比如各種文檔、模型、源代碼以及測試腳本等，我們把這些大家勞動的成果統(tǒng)稱為工件（Artifact）。對于一個軟件開發(fā)組織來說，這些工件就構(gòu)成了組織的核心資產(chǎn)。對于如現(xiàn)金、有價證券之類的資產(chǎn)，我們都會準備一個保險箱，好好地保存；對于軟件資產(chǎn)，我們也需要相似的措施。所以，軟件配置管理工作的第一步就是建立一個安全、可靠的存儲庫（Repository），用于保存組織的核心軟件資產(chǎn)。

這個庫對于開發(fā)團隊來說，就像是財務(wù)室里的保險箱。因此，容錯能力和高可靠性是這個庫最重要的屬性。除此之外，隨著組織的增長，置于庫中的數(shù)據(jù)會越來越多，為保證運行效率，庫的可擴展性也是非常重要的一個屬性。

對于存儲庫來說，良好規(guī)劃的備份和災(zāi)難恢復過程是必不可少的。令人驚訝的是，很多軟件組織在這方面都沒有給予必要的重視，因而也給組織的發(fā)展留下了嚴重的隱患，一旦災(zāi)難發(fā)生，后果不堪設(shè)想。

在建立好存儲庫以后，需要做的工作就是確定將哪些工件置于庫中。根據(jù)實際需要，組織可能會決定只將正式文檔、模型文件、源代碼、發(fā)布版本等文件放入庫中，而對于臨時文檔、編譯時產(chǎn)生的中間文件等，則不將它們放入庫中。我們把放入庫中的文件稱之為配置項（Configuration Item）。

2、控制并且審計（Audit）對于工件的修改

在標識相關(guān)的工件并將它們置于存儲庫中以后，我們需要建立對于這些工件的修改控制機制以及審計機制。

庫里的工件不是誰想修改就可以修改的?？刂茩C制必須保證只有拿到授權(quán)的人員才能對相關(guān)工件進行修改，而審計機制則保證修改的動作被完整地記錄，也就是說，誰修改了這個工件，什么時候做的修改，為什么原因做出這個改動，以及修改了哪些地方（Who、When、Why、What）。

審計機制通常通過“檢出/檢入”（Check out/Check in）模式得到實現(xiàn)。在這種模式下，工件一旦入庫，讀寫權(quán)限就變成只讀（read only），如果要對該工件進行修改，則需要通過“檢出”這個步驟；在修改結(jié)束以后，如果希望將修改的成果入庫，則需要通過“檢入”這個步驟。在經(jīng)過一次“檢出/檢入”步驟以后，會形成該工件新的版本，因此也有人把上邊的過程稱之為“版本控制”（Version Control）。在版本控制過程中，如果利用一些配置管理工具（或者版本控制工具）的支持，則可以自動地記錄審計工作所需的四個“W”（Who、When、Why、What）。

3、設(shè)立并管理基線

通過審計機制我們可以保存一個工件完整的變更歷史；但是一個項目通常是由成百上千個工件構(gòu)成的，每個工件在變更過程中都會形成一系列的版本，如何確認系統(tǒng)在某個時刻分別由哪些工件的哪些版本構(gòu)成？這就需要引入一個概念：配置（Configuration）。對于軟件系統(tǒng)來說，在開發(fā)過程中某個時刻存儲庫中所有工件的一個“快照”（snapshot），就形成一個“配置”。對于一些重要時刻的系統(tǒng)配置，我們可以使用基線（Baseline）來進行標志。

IEEE對于基線的定義是：已經(jīng)通過正式復審和批準的某規(guī)約或產(chǎn)品，它因此可以作為進一步開發(fā)的基礎(chǔ)，并且只能通過正式的變更控制過程進行改變.簡單地說，基線就是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨后的工作基于這個標準進行，并且只有經(jīng)過授權(quán)后才能變更這個標準。建立一個初始基線后，以后每次對它進行的變更都將記錄為一個差值，直到建成下一個基線。

建立基線的主要原因是：重現(xiàn)能力、可追蹤性和報告能力。

重現(xiàn)能力是指返回并重新生成軟件系統(tǒng)給定發(fā)布版本的能力。可追蹤性建立項目各種類型工件（需求、設(shè)計、實現(xiàn)、測試等）之間的橫行依賴關(guān)系，其目的在于確保設(shè)計滿足需求、代碼實施設(shè)計以及使用正確代碼編譯生成可執(zhí)行文件。報告能力來源于一個基線內(nèi)容同另一個基線內(nèi)容的比較，基線比較有助于程序調(diào)試并生成發(fā)布說明（Release notes）。

建立基線有以下幾個好處：

(1) 基線為開發(fā)工件提供了一個定點和快照。新項目可以從基線提供的定點之中建立。

(2) 當認為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法。

(3) 可以利用基線重新建立基于某個特定發(fā)布版本的配置，這樣也可以重現(xiàn)被報告的錯誤。

在開發(fā)過程中，需要定期建立基線以確保團隊開發(fā)人員的工作保持同步，通常，在項目生命周期中的里程碑處定期建立基線。

4、記錄并跟蹤變更請求

以上我們談?wù)摰亩际菍τ诠ぜ淖兏顒拥膶嵤旅嫖覀円劦降氖擒浖渲霉芾淼牧硪粋€方面：對于變更請求的管理。這是變更活動的源頭。

著名的軟件大師Brooks曾經(jīng)談到導致軟件開發(fā)困難的一個原因就是軟件的可變性。大家都知道，各種要素，如市場的變化、技術(shù)的進步、客戶對于項目認識的深入等等，都可能導致軟件開發(fā)過程中的變更請求的提出，而且承認這種變更請求的合理性也已經(jīng)是工業(yè)界的共識。

但是，如果缺乏對于變更請求的有效的管理能力，紛至沓來的變更就會成為開發(fā)團隊的噩夢。缺乏有效的變更請求管理會導致以下一些問題：

（1） 軟件產(chǎn)品質(zhì)量低下，對一些缺陷的修正被遺漏；

（2） 項目經(jīng)理不了解開發(fā)人員的工作進展，缺乏對項目現(xiàn)狀進行客觀評估的能力；

（3） 開發(fā)人員不了解手頭工作的優(yōu)先級別，可能出現(xiàn)將緊急的事情放在一邊、而工作在一般優(yōu)先級任務(wù)上的情況。

變更請求管理的復雜程度與變更的具體類型有關(guān)。簡單地說，變更請求管理會涉及到變更請求的提交、變更請求的復審、變更任務(wù)分配、變更結(jié)果的驗證等一系列活動。通常，變更請求管理的流程是：由請求者提交變更請求，變更控制委員會（Change Control Board，CCB）召開CCB復審會議對變更請求進行復審，以確定該請求是否為有效請求。如果是，則基于項目團隊所確定的優(yōu)先級、時間表、資源、變更難度、風險、嚴重性以及其他相關(guān)標準，判定對該變更的修改程序，并分配實施變更任務(wù)的人力資源和時間資源；變更任務(wù)實施人員負責實施該變更；實施結(jié)束以后提交驗證人員，由驗證人員負責對變更結(jié)果進行驗證，如果變更成功則通知相關(guān)人員，否則由變更實施人員返工。

典型的變更請求管理如需求變更管理、缺陷追蹤等。實施有效的變更請求管理有以下好處：

（1） 提高軟件產(chǎn)品質(zhì)量；

（2） 提高開發(fā)團隊溝通效率；

（3） 幫助項目管理人員對產(chǎn)品狀態(tài)進行客觀的評估。

關(guān)于變更請求管理的詳細過程以及相關(guān)準則PMT將在相關(guān)報告中闡述。

5、維護穩(wěn)定、一致的工作空間

在我們把相關(guān)工件納入集中的存儲庫、大家也都遵照“檢出/檢入”的工作模式對工件進行修改以后，下一步的工作就是要為每位開發(fā)人員設(shè)定“私有”的工作區(qū)，或者叫做工作空間。 工作空間通常以特定的基線為基礎(chǔ)創(chuàng)建，要求能夠做到為指定的任務(wù)方便地取出正確的工作版本建立私有工作空間；開發(fā)人員根據(jù)項目要求在自己的私有空間中對工件進行修改和測試活動，而與其他開發(fā)人員相對保持隔離，也就是說，自己的修改活動不會受到他人的影響，也不會影響到其他開發(fā)人員。但是，在保持隔離的同時，又應(yīng)該提供相應(yīng)的機制，當開發(fā)人員希望共享工作成果的時候，能夠很方便地實現(xiàn)共享。

開發(fā)人員日常的開發(fā)工作都是在工作空間里進行的，因此，穩(wěn)定性應(yīng)該是工作空間首要的特性，只有高度穩(wěn)定的工作空間才能保證開發(fā)人員的工作效率。