本章內容提要

軟體配置管理的作用
軟體配置管理的相關概念
建立軟體配置管理環境
版本控制
系統整合
分支管理
變更管理
配置審計和配置狀態報告
配置管理過程
軟體配置管理工具

第一節  軟體配置管理的作用

星形網拓撲結構

不同程式設計師對程式的更改會產生衝突

軟體專案中可能遇到如下的問題:

找不到某個檔案的歷史版本；
開發人員使用錯誤的程式版本；
開發人員未經授權修改程式碼或文件；
人員流動，交接工作不徹底；
無法重新編譯軟體的某個歷史版本；
因協同開發，或者異地開發，版本變更混亂導致整個專案失敗；
……

•  軟體專案進行中面臨著持續不斷的變化，變化可能導致混亂，而軟體配置管理就是用於控制變化。
  

•  軟體配置管理(Software Configuration Management, SCM)是指一套管理軟體開發和維護過程中所產生的各種中間軟體產品的方法和規則。它是控制軟體系統演變的學科。

軟體配置管理的目標

• 標誌變更

• 控制變更

• 確保變更正確實現

• 向受變更影響的組織和個人報告變更

軟體配置管理的效果

• 記錄軟體產品的演化過程。

• 確保軟體開發者在軟體生命週期中的各個階段都能得到精確的產品配置。

• 最終保證軟體產品的完整性、一致性、可追溯性。

軟體配置管理的主要功能

• 版本控制：採用相應的流程和工具，對軟體開發過程中產生的各種檔案的版本進行管理。是軟體配置管理的核心內容。

• 變更管理：為防止開發人員對軟體的隨意變更而進行的管理上的稽核過程，包括變更請求、變更評估、變更批准/拒絕、變更實現。

• 其它：配置審計、配置狀態統計等。

第二節  軟體配置管理的相關概念

• 軟體配置項(Software Configuration Item, SCI)

    軟體配置管理的物件，一個軟體配置項是專案中一個特定的、可文件化的工作產品集。
    常見的軟體配置項：需求規格說明書、設計規格說明書、原始碼、測試計劃、測試用例、使用者手冊。
    構造軟體的工具和軟體賴以執行的環境也常常列入配置管理的範疇。

• 基線(Baseline)

    已經正式通過複審和批准的某規約和產品，它因此可作為進一步開發的基礎，並且只能通過正式的變化控制過程來改變。

• 各開發階段結束時形成里程碑基線。

在軟體配置管理中，基線的含義在不同的應用場合會有所不同。

• 軟體配置控制委員會(Software Configuration Control Board, SCCB)

    負責管理軟體配置項變更的組織。

評估變更
批准/拒絕變更申請
在專案生存期內規範變更申請流程
對變更所產生的後續影響進行監督和控制。
與專案管理層溝通

第三節 建立軟體配置管理環境

在企業級：
（1）建立工具集
（2）建立規範
在專案級：
（1）識別和標誌配置項
（2）建立配置庫

3.1 企業級的工作

（1）建立工具集

• 一個企業的配置管理工具應該統一購買、安裝、設定和維護。以節約資源，提高工作效率。不要每個專案都搞一套工具。

• 情況差別很大的專案可以考慮使用不同的工具，但要儘量減少工具的種類。

（2）建立軟體配置管理規範

• 在企業級建立標準的軟體配置管理規範，如變更控制流程、版本編號規則、缺陷跟蹤流程、分支策略等。

• 一個軟體專案可使用標準的軟體配置管理規範，如果有特殊需要，可對其進行剪裁，或重新制定規範。重新制定的專案規範，如果今後有很多類似的專案，可把其上升為企業級標準規範。

3.2 專案級的工作

（1）識別和標誌配置項

• 將軟體專案中需要進行控制的工作產品定義為軟體配置項（SCI）。

• 配置項分為兩類：

基本配置項：軟體開發者在專案開發過程中所建立的基本工作單元。
整合配置項：一個整合配置項是基本配置項或其它整合配置項的集合。

（2）建立配置庫

• 配置管理庫，簡稱配置庫，是配置管理環境的核心，使用配置管理工具建立。

    配置庫儲存配置項（SCI）、修改請求、變化記錄等，並提供對庫中所儲存檔案的版本控制。

• 為不同的人員（如開發人員、測試人員、整合人員、專案管理者）分配不同的訪問配置庫的許可權。

• 配置庫中的配置項每經歷一次改變將形成一個新的版本並被分配相應的版本標誌。配置庫中通常以增量方式儲存配置項的各個版本，以減少空間消耗並增強版本處理的靈活性。

• 例如：一個配置項最初從開發者的工作空間提交到配置庫，形成最初版本，如1.0，此後每修改和提交一次版本就會變化，如1.1，1.2，……，配置庫採用增量方式儲存每個版本，以節省空間。可以在任何時候得到配置項的任何版本。

第四節 版本控制

4.1 配置庫的檢入檢出機制
4.2 防止版本覆蓋的兩種方法
4.3 適時更新工作空間
4.4 記錄原始碼整體版本
4.5 儲存安裝包
4.6 軟體版本編號方法
4.7 專案外資源的版本控制

4.1 配置庫的檢入檢出機制

    

配置庫的檢入檢出和版本控制機制解決了團隊軟體開發中的兩個重要問題：

• 訪問控制：保證具有相應許可權的人員才能修改配置項。

• 並行控制：保證不同人員同時對某配置項進行的修改不會互相覆蓋。

4.2 防止版本覆蓋的兩種方法   

• 第一種方法：序列（加鎖-解鎖）。

    程式設計師在修改檔案之前，版本控制工具將檔案加鎖，其他人不能對它進行修改。該程式設計師修改完畢，將檔案再檢入到配置庫中時，版本控制工具再將其解鎖，其他人才能進行修改。
    特點：效率較低，應儘量減小加鎖範圍。

• Visual SourceSafe (VSS)，微軟出品的版本控制工具，預設支援第一種方法。通過設定，也可支援第二種方法。

• 第二種方法：並行（修改-合併）。不同的程式設計師可同時修改某一檔案，修改完成後，在某一合適的時刻進行合併（由版本控制工具輔助完成）。

   特點：效率較高
  Subversion（SVN）、ClearCase(CC)都同時支援以上兩種方法，但以第二種方法為主。

  市面上還有幾十種版本控制工具，它們都至少支援以上兩種方法中的一種

配置項的演化圖(Evolution Graph)

4.3 適時更新工作空間

• 開發人員在自己的工作空間中工作的時候，配置庫中可能已有了很大的變化，其他開發人員已向配置庫提交了很多程式碼。這樣，自己的工作空間中的程式碼就有過時的風險，使得自己開發的程式碼不能與其他人最新的程式碼共同工作。

• 因此開發人員需要適時地更新（update）自己的工作空間。

• Subversion中的更新就叫“update”。其它一些工具還有另外的稱呼，如變基(Rebase)，重新配置(Reconfig)等。

• 什麼時候更新？

1.  在開始一個新任務的時候，如開發一個新功能模組，修改一處程式碼等。這時的更新建立了關於這個任務的初始工作環境。不要在一開始的時候就落伍
2.  在完成任務的過程中，可能需要更新。特別是在任務持續時間較長的情況下。要跟上時代的步伐
3.  在任務完成後，即將提交的時候，最好做一次更新，並測試一下，以保證自己新寫的程式碼，可以與別人的程式碼一起工作。保證提交有基本的質量。做事要善始善終

    注意：更新工作空間也不必要太頻繁

4.4 記錄原始碼整體版本

• 在軟體專案週期的不同時期會產生不同的版本，且在同一時期也會有不同的版本。

• 因此需要記錄軟體的整體版本，明確軟體的每個版本都包含哪些特定版本的源程式檔案。

記錄原始碼整體版本的方法：

• 方法一：在軟體開發過程中，當某一版本形成時，複製其所有原始碼。一些版本控制工具提供的複製(Copy)命令即可完成這一任務。

• 方法二：記錄某個整體版本，只需要記錄這個版本是由哪些檔案的具體哪個版本組成的。因此可以在相關檔案的特定版本上打個標籤(Label/Tag)，標籤的名字，就是整體版本的名字。

• Subversion支援以上第一種方法。此外，Subversion總是自動地產生新的整體版本。程式設計師的每一次提交，都會產生一個新的原始碼整體版本號，將這一整體版本號分配給所有源程式檔案。因此Subversion實際上也支援以上第二種方法。

• ClearCase採用的是第二種方法。

基線及其質量狀態

• 在談論原始碼版本管理的時候，基線（Baseline）的含義是，被明顯地標誌和記錄下來的原始碼整體版本。

• 基線具有質量狀態：

1.  剛剛標記出來的時候，其質量未知（Initial）；
2.  編譯連結和打包通過後，其質量是通過構建的（Built）；
3. 如果通過了一定程度的測試，其質量是通過測試的（Tested）；
4. 如果通過了詳盡測試，可以釋出，其質量是可釋出的（Released）。

• 當基線由一個較低的質量狀態達到了一個更高的質量狀態時，就產生了一個基線提升（Baseline Promotion）。

• Subversion可以用版本屬性來表示基線的質量狀態。

• ClearCase UCM明確地支援基線提升。不僅有相應的命令，也可以在圖形介面中操作和檢視。

4.5 儲存安裝包

• 在釋出軟體之前，或在對軟體進行系統測試或驗收測試之前，需要生成安裝包。安裝包同樣需要儲存，並標上相應的版本號，原因如下：

1.  將來在需要該安裝包時，可以迅速準確地得到它，不必從原始碼開始重新編譯、打包，這樣可以節省時間。
2.  使用者或系統測試人員發現的軟體Bug，有可能是由安裝包的生成過程造成的，儲存了安裝包，可以快速地定位Bug的原因。

• ClearCase不僅儲存和管理原始碼，也儲存和管理由原始碼生成的內容，這些內容被稱為“匯出物件”（Derived Object），包括可執行檔案、庫檔案、資料檔案等。安裝包也是匯出物件的一種。

4.6 軟體版本編號方法

• 原始碼檔案、文件檔案和產品整體（原始碼整體和安裝包）都有版本號（Version Number）。

• 版本號的命名，目前業界尚無統一做法。

產品整體版本編號
       數字順序型版本編號
              普通版本編號
              α和β版本編號
       屬性版本編號
配置管理工具的自動版本編號

數字順序型版本編號

• 普通版本編號

    產品的版本號由若干數字組成，數字之間用“.”分隔。一種典型的編號策略如下：
    x.y.z，x為主版本號，y為特徵版本號，z為缺陷修復版本號。

1. 主版本號的增加表示提供給客戶的主要產品功能的增強。
2. 特徵版本號的增加表示產品新增了一些特徵或做了一些重要修改。
3. 缺陷修復版本號的增加表示在軟體產品上做了一些缺陷修復工作。

• 當某一級版本號增加時，其下級版本號要清零。

• α和β版本編號

1. 在普通版本編號後面增加一個大寫字元A或者B來分別表示α版本或β版本。例如1.2.4A或1.2.4B。
2. 如果存在多次的α釋出和β釋出，可在A或B後面新增一個數字來說明發布的次數，例如：1.2.5A1，1.3.0B2。

屬性版本編號

• 開發團隊內部對版本號也有要求。

• 把版本的重要屬性反映在版本標識中。可以包括的屬性有：客戶名、開發語言、開發狀態、硬體平臺、生成日期、技術特徵、質量狀態等。例如：

    J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122
    

配置管理工具的自動版本編號

• 為了唯一識別配置庫中某個配置項的某個版本，配置管理工具會自動為配置項進行版本編號，其編號規則固化在配置管理工具中。

• 例如常用的兩級製版本編號規則：前一級標誌分支，後一級標誌同一分支中的特定版本，多個前後級標誌串聯起來可以表示任何複雜的版本。兩級標誌之間用“.”或“/”連線，分支的標誌可能使用字母，也可能使用數字。

4.7 專案外資源的版本控制

• 除專案中所產生的原始碼、文件、資料等配置項外，專案所使用的一些外部資源也應納入版本控制。

• 把外部資源納入版本控制並不意味著一定要把它們放入配置庫。

• 以二進位制形式存在的軟體包一般不適合放進配置庫，特別是當它很大的時候。可以儲存在共享目錄裡，加上適當的描述說明和適當的存取許可權。

• 在專案中，要記錄清楚使用了哪些外部資源，什麼版本。可以用文字檔案或表格的形式記錄，並放入配置庫中。

第五節 系統整合

5.1 整合有什麼作用？
5.2 整合的一般步驟
5.3 整合中的測試和糾錯
5.4 使用整合成果
5.5 持續整合和持續交付
5.6 多層整合
5.7 整合中的構建

5.1 整合有什麼作用？

• 系統整合（System Integration），簡稱整合，就是把軟體產品的各個組成部分組合在一起，使產品作為一個整體是可以執行的。

• 整合要對軟體進行編譯、連結和打包，並要對軟體產品進行粗略測試(Rough test)，也稱冒煙測試(Smoke test)，證明其基本可執行，值得送交測試人員進行詳細測試。

軟體開發過程分析

軟體開發一般按如下過程：
（1）開發人員在開始一個開發任務前，用配置庫的最新程式碼更新自己的工作空間，編譯連結。
（2）開發人員分別在自己的工作空間中完成開發任務。
（3）開發人員在提交前，用配置庫中的最新程式碼更新自己的工作空間，編譯、連結和測試(主要測本次任務所做的修改)，通過後提交到配置庫中。
（4）為了保證軟體質量，測試人員要定期或不定期地從配置庫中取出所有最新程式碼，編譯、連結和打包後，進行系統地、全面地測試。測試過程中如果發現bug，提交到缺陷跟蹤系統中，進行修復。
以上開發過程在規模較大，開發人員較多的專案中，很可能出現以下問題。
（1）測試人員從配置庫中取出最新程式碼後，編譯連結不通過，通過後，又幾乎不能執行，阻塞測試程序。
（2）開發人員在用配置庫中的最新程式碼更新自己工作空間後，經常編譯連結不通過，阻塞開發程序。

為什麼會出現問題？

• 開發人員由於疏忽大意等原因，提交的程式碼有質量問題，或忘記提交一些檔案。

• 即使開發人員的工作完全正確（提交前已更新了工作空間，並通過了測試），仍有可能出現以上問題，因為不同開發人員所做的程式改動，可能是不相容的。

怎樣解決問題？

• 加入整合工作：定期或不定期地把配置庫中的最新程式碼取出，進行編譯、連結、打包和粗略測試，及時發現和解決問題，使配置庫中的程式碼具有一定的質量，並形成基線，供測試和開發人員使用。

• 開發和測試人員即使不使用基線，也同樣能從整合得到好處。

由誰來整合？

• 開發人員要適時更新自己的工作空間，使自己開發的模組能夠與產品整體協調工作，這實際上也是整合工作。只是其關注點是區域性性的。

• 整合工程師（Integrater/Integration Engineer）也稱構建工程師（Buider/Build Engineer）負責全域性性的整合，他把各開發人員提交的程式碼修改彙集在一起，確保產品整體是整合的，並且具有一定的質量。這種整合工作稱為狹義整合（Narrow Integration），而更一般意義上的整合稱為廣義整合（General Integration）。

5.2 整合的一般步驟

• Step 1：確保開發人員都提交了相關的原始碼。為了更嚴格地進行控制，可以預先制定一個列表，規定本次要整合哪些工作，在整合開始前檢查一遍是不是所有規定的模組都已提交，列表之外的改動有沒有被提交。在必要的時候（比如產品即將釋出前），每次提交都必須得到授權。

• Step 2：凍結或者標識將要整合的原始碼。必須明確集成了哪些內容，即集成了哪些檔案，以及檔案的哪些版本。為此需要凍結原始碼，在整合前禁止開發人員向版本庫提交，或者用打標籤的方式把當前的整體版本標誌出來。

• Step 3：取出要整合的原始碼。最好存放在一個全新的工作空間，不包含一些雜項，如一些編譯的中間檔案和結果檔案，尚未提交的本地修改等。

• Step 4：編譯、連結和打安裝包。這一過程通常稱為構建（Build）。如果遇到了問題，需要修改原始碼，回到第一步。

• Step 5：安裝並粗略測試。如果發現問題，修改了原始碼後，回到第一步。

• Step 6：標誌和儲存整合成果。整合成果有兩個：一個是原始碼的整體版本（基線），一個是生成的安裝包。通常還要生成一個“釋出說明”，說明本次集成了哪些功能和修改。

• Step 7：通知相關人員本次整合完成。即釋出整合成果。

5.3 整合中的測試和糾錯

• 整合過程中，編譯連結通過後，要做粗略測試，或稱冒煙測試。

• 測試不宜太多太細，否則會降低整合的頻率，延緩基線的產生，阻塞後續的開發和測試工作。

• 粗略測試的目的是排除那些嚴重的、對後續工作有嚴重影響的錯誤。

• 把所有可能出現的嚴重問題按照嚴重程度排序，選擇前面的若干問題，作為檢測物件。

• 針對這些問題編寫測試用例。

• 如果能自動執行這些測試用例，則可以顯著提高整合的效率，提高整合的測試強度，有利於頻繁地整合。

• 如果在測試中發現了問題，通常採取以下兩種方式處理：

1.  對於容易解決的問題，立即著手解決；
2. 如果問題比較棘手，需要開發人員仔細研究，那麼通常應把引起問題的提交從配置庫中剔除，也就是回退合併，使本次整合不再包含該提交。

• 開發人員在修復問題後，再次提交到配置庫，與此同時，配置庫中還可能出現了其他開發人員正常的提交，兩者混雜在一起，如何處理？

• 方法一：在整合工程師開始整合之時，先把配置庫鎖上，除非允許，禁止提交。如果整合過程中發現了問題，由相關人員修復，在取得許可權後，把修復提交到配置庫。直到整合完成產生基線後，再解鎖配置庫。該方法較保守，可能會阻礙開發過程。

• 方法二：在整合工程師開始整合之時，把配置庫中要整合的分支（稱為“整合分支”）鎖上。如果在整合過程中有開發人員要提交，就開闢臨時分支，讓程式設計師提交到臨時分支上。整合完成後，再把該分支上的內容合併回整合分支。

• 方法三：整合工程師始終不鎖整合分支。當整合遇到問題時，如果整合分支上已經有新的正常提交，就為本次整合開闢出一個臨時分支，把為本次整合所做的修復提交到臨時分支上，並在臨時分支上產生基線，再把基線合併回整合分支。

• 方法四：整合工程師始終不鎖整合分支。當整合遇到問題時，即使整合分支上已經有新的正常提交，也把為本次整合所做的修復提交到整合分支上。當整合工程師再次編譯構建時，不僅包括了為本次整合所做的修復，也包括了新的正常提交。本方法最為簡便，但有一定的風險。

• 究竟採用哪種方法，視具體專案情況而定。

5.4 使用整合成果

• 測試人員會使用整合生成的安裝包進行詳盡的測試。

• 整合所產生的軟體原始碼整體的一個基線對開發人員是有用的。

• 開發人員在更新自己的工作空間時，如果每次都是更新到軟體最新的程式碼，則有可能出現編譯連結不通過的情況，阻礙自己的開發工作。

• 解決方法：更新工作空間時，不更新到配置庫中的最新內容，而是更新到最近一次整合產生的基線。這種方法稱為間接工作流（Non-immediate Workflow）。

• 而更新到最新內容的方法稱為直接工作流（Immediate Workflow）。

• Subversion預設使用直接工作流，也可以實現間接工作流。ClearCase預設使用間接工作流，也可以設定為直接工作流。

間接工作流和直接工作流

間接工作流的缺點

• 1.如果一個程式設計師需要拿到其他程式設計師最新的程式碼修改才能繼續工作，而其他程式設計師的最新程式碼修改還沒有被整合到基線中，那麼只有等待，直到下一次整合完畢後產生新的基線。

• 2.程式設計師在提交程式修改時，只能保證自己的修改在上一個基線裡沒有問題，而不能保證在版本庫中最新的軟體版本里沒有問題。

解決方法

• 方法1：做出折衷，如果需要的最新程式碼不在基線中，就使用直接工作流；在提交修改之前，也使用直接工作流。

• 方法2：加快整合的頻率，快到配置庫裡的最新程式碼一旦有問題，幾乎可以立即被發現，並被立即解決。從而保證即使是用直接工作流，每次更新得到的也是被整合後有一定質量的基線。

5.5 持續整合和持續交付

• 為了儘可能快地發現和糾正配置庫裡原始碼的問題，保證在絕大部分時間裡配置庫裡的原始碼是沒有問題的，不對開發人員產生負面影響，需要提高整合的頻率，例如每天、每半天、每兩小時甚至更短的時間間隔，執行一遍整合，這種方法稱為持續整合。

• 提高整合頻率也要有個度，因為每次整合要付出一定代價（編譯、連結、打包和粗略測試）。當提高整合頻率的好處被所付出的代價抵消時，就要考慮是否應該這樣做。

持續整合的自動化

• 由於整合的頻率很高，持續整合通常需要自動化工具的支援，將編譯、連結、打包、部署和測試（通過自動化測試指令碼）連貫地自動執行下來，並自動報告整合成功或所發現的問題。

• 自動化的整合不僅可以提高整合的速度，還可以提高整合的準確性和可重複性。

• CruiseControl是開源的持續整合工具。

• Build Forge是IBM Rational出品的構建和釋出管理系統，能夠很好地支援持續整合。

• 持續整合工具可以在適當時機啟動整合過程，例如週期性地（如每兩分鐘）探測整合分支上有沒有新的提交，一旦有新的提交就啟動新一輪的整合。

• 持續整合工具可自動把配置庫中的最新（整合分支末端的）程式碼下載到本地。這通常呼叫版本控制工具的一行命令就能完成。

• 自動執行編譯、連結、打包操作。這通常呼叫開發工具的一行或幾行命令就能完成。

• 自動執行粗略測試。這要求預先設定好測試環境，準備好測試資料，並編寫自動測試指令碼。

• 最後自動建立基線，收集相關資訊，例如本次整合包含了哪些修改等，生成“釋出說明”。

• 以上過程的任意一步如果出現了問題，持續整合工具會立即報告給相關人員（通過郵件、簡訊等方式）。

自動化的持續整合

頻繁更新和提交

• 開發人員頻繁地更新工作空間和提交自己的改動，也能儘早發現原始碼整合問題。

• 開發人員使用配置庫中的基線或最新程式碼更新自己的工作空間後，進行編譯、連結和檢測（屬於廣義整合），可發現一部分問題。

• 開發人員頻繁地提交改動，也有利於整合工程師儘早發現和排除程式碼整合問題。

• 頻繁地提交少量改動還有利於減少不同開發人員執行的任務之間的等待。

• 提高更新和提交的頻率也要有個度，因為這些操作需要時間。

• 要特別注意，不要因為提交邏輯上不完整的改動而對其他開發人員、測試人員和整合工程師造成困擾。

• 不要對提交做一些僵化的硬性規定。例如：在提交前必須執行完一個較大的、不能自動執行的測試用例集；每天下班前必須提交當天的修改。

持續交付

• 當完成了軟體的某一版本後，可將軟體交付給使用者使用，這種交付（delivery）活動往往不是一次性的，而是多次的，甚至是頻繁的，即持續交付（continuous delivery）。

• 持續交付的目的有以下兩個：

1.  儘快發現和解決系統在使用者使用環境中出現的問題。
2.  儘快向用戶提供新功能，為使用者創造價值，並儘快對市場新動向做出反應。

5.6 多層整合

• 典型情景：幾個人共同完成一個大的任務，需要緊密配合，頻繁交流。此時他們每個人所完成的任務不宜頻繁提交到開發團隊所有人使用的公共環境裡。因此他們有必要組成一個“小圈子”，每個人完成了自己的程式模組後，先提交到小圈子裡，在小圈子裡整合無誤後，再提交到公共環境中，與其它程式再進行整合。

• 兩層或兩層以上的整合稱為多層整合（Multilevel Integration）.

• 使用多層整合的情況：

1.  多個人合作完成一個任務，需要互相高度配合，而該任務作為一個整體，與其它任務關聯不大，此時應考慮使用多層整合。
2. 大型專案開發人員眾多，原始碼也龐大複雜。研發團隊分成了若干研發小組，每個小組負責完成一個元件（或一個子系統），此時可以考慮在每個小組內做第一層整合，然後再做小組間的總的整合。

複合基線

• 一個系統是由不同的元件組成的，各元件的整合工程師都會通過整合形成本元件的一系列基線。

• 系統的總體整合工程師取得各個元件的特定基線，通過整合，形成系統整體的一個基線，即複合基線（Composite Baseline）。

• 複合基線在基於元件的軟體開發中有重要作用。

• ClearCase UCM提供了複合基線功能。Subversion需要手工記錄複合基線，或通過編寫指令碼來實現複合基線功能。

元件整合的工作方式

• 方式1：通常情況下，元件的整合是在最近一次系統總體整合建立的複合基線上工作。元件整合工程師取得複合基線中其它元件的基線，與本元件一起整合。

• 方式2：也有可能，元件整合工程師需要取得其它元件的最新基線，與本元件一起整合。

• 方式3：在少數情況下，元件整合工程師需要取得其它元件中最新的程式碼修改，然後與本元件一起整合。

• 具體使用哪種方式，視具體情況而定。

元件開發人員的工作方式

• 方式1：使用配置庫中最新的程式碼更新自己的工作空間，即直接工作流。

• 方式2：使用配置庫中本元件和其它元件的最新基線更新自己的工作空間，屬間接工作流。

• 方式3：使用配置庫中的複合基線更新自己的工作空間，也屬間接工作流。

• 使用哪種方式也取決於具體情況。

• 大型專案中，元件的開發人員通常只修改與自己相關的一個或幾個元件，而其它元件對他來說應該是隻讀的，以防止隨意修改。

工具支援

• 以上不同工作方式的工具支援：

• Subversion可讓程式設計師人工進行配置和設定，也可以藉助一些指令碼來完成。

• ClearCase引入了UCM專案的概念。一個UCM專案包括了一個或多個元件的開發。一個軟體專案可以包括多個UCM專案。通過合理地設定UCM專案，進而適時建立基線和複合基線，能夠對基於元件的開發起到不錯的支援作用。有時也需要寫一些指令碼來完成特定功能。

5.7 整合中的構建

• 構建(Build)就是從原始碼生產出安裝包的過程。包括：

1.  編譯
2. 連結：生成可執行程式
3. 打包：把所有對使用者有用的東西打成一個安裝包

• 構建有時可能不包括打包，比如程式設計師編譯和連結程式後進行測試，此時構建過程就只包括編譯和連結。

保證構建的可重複性

• 構建可能會遇到的問題：

1. 產品的某個版本，在原始碼沒有改變的情況下，這次構建後產品沒問題，下次構建出現了Bug。
2.  產品的某個版本，一個人構建後產品沒有問題，另一個人構建後卻出現了問題。
3.  產品的某個版本，現在構建沒有問題，一段時間（也許是幾年或者更長）後再構建卻出現了問題。

• 構建結果的不可預測會給軟體開發和維護帶來困擾！

• 保證構建的可重複性就是指保證每次構建一個具體的產品版本，得到的結果是相同的。

為了達到這一要求，需要保證：

• 構建的輸入（所有原始碼、文件、資料等）是固定和明確的。

• 構建的工具和環境是固定和明確的。包括特定品牌和版本的編譯器、打包工具、作業系統，以及硬體配置。

• 引數設定是固定和明確的。包括編譯、連結和打包的命令引數，工具和環境的配置引數（例如作業系統的環境變數）。

• 構建過程是固定和明確的。比如Ant檔案、相關的指令碼；操作的執行順序等。

為了做到以上幾點，通常有以下策略：

• 自動化：儘可能將構建過程自動化，減小出差錯的可能性。例如使用構建工具來執行指令碼。

• 文件化：詳細記錄構建過程、構建環境等資訊，使任何人都可根據這個記錄文件來正確執行構建過程，得到正確結果。

• 與原始碼的版本繫結：將構建工具、配置引數、執行指令碼、說明文件等與原始碼一起放到配置庫中。一旦匯出了特定版本的原始碼，也就同時匯出了對應該版本的所有這些內容。

加快構建速度

• 全量構建：完全重新編譯原始碼，繼而連結、打包，不利用上次構建所生成的中間結果。

• 增量構建：儘可能地利用上次構建的成果，只重新編譯那些發生了改變（和受改變影響）的原始碼。特點：速度更快，但不如全量構建可靠。

原則：

• 在追求構建速度的時候，傾向於使用增量構建，例如程式設計師自己構建的時候。

• 在強調構建的可靠性的時候，傾向於使用全量構建，例如整合工程師進行構建的時候。

其它措施

• 使構建自動化：使用Ant、Makefile等構建工具，將整個構建過程自動化。

• 分散式構建：把構建任務分解，分佈到多個計算機（或多個CPU）上並行構建。

ClearCase自帶的構建工具Clearmake支援Unix平臺上的並行分佈構建。

第六節 分支管理

分支(Branch)是軟體版本演化圖中的一條路徑，是軟體的一個獨立演化的版本序列。
在配置庫中，各分支是獨立儲存的。

• 在軟體版本演化圖的眾多分支中，有一條是主線（mainline）,也稱主幹（trunk）。所有其它分支都從主線分出，並有可能會合並回主線。

1.為什麼要使用分支？

• 原因一：需要建立一個不同的版本。

• 原因二：一組人員需要在一個相對獨立的環境中互相配合共同完成一個大的任務。

• 深層次原因：軟體開發程序面臨著兩個基本問題（一對矛盾），即適當隔離和適當共享。

• 適當隔離：在工作過程中，各人或各組需獨立地工作，不希望被別人意外地干擾，也不希望干擾別人。

• 適當共享：各人或各組的工作，應該在適當的時候，以適當的方式，共享和整合。

• 分支同時對隔離和共享提供了支援。

1.  一條分支被建立後，它的生長是獨立的，工作在一條分支上，不會與主線或其它分支相互影響。
2.  分支的起點是分支的基礎，是分支繼承的內容；不同分支上的工作成果，可在適當的時候合併。

2.分支的合併

• 分支的合併是指把一條分支上的版本的內容，帶到另一條分支（例如主線）上。分為兩種情況。

1.  整個分支上的工作成果均合併過去。

    2. 只將分支上的一部分工作成果合併過去

• 分支的合併是一種複製行為，合併後被合併分支上的各版本不會受任何影響。

3.分支典型應用一：多層整合

• 整個專案團隊使用主線，“小圈子”是一個分支。在分支上的工作不影響主線。在分支末端進行一次整合，然後合併到主線上。

4.分支典型應用二：管理交迭

• 交迭（Overlap）就是指軟體不同版本的開發在時間上重疊。

• 典型情景一：某軟體的1.0版本基本成型，等待發布。此時軟體的大部分功能都已完成，但還有少量輔助功能沒有完成，並可能存在很多缺陷，等待測試和修復。在1.0版的完善和測試期間，大部分程式設計師處在空閒狀態，等待測試人員通知修復缺陷。直到1.0版軟體達到質量要求，釋出出去，然後再開始2.0版的開發。

• 解決方法：

        為了使1.0版的完善工作和2.0版的升級開發工作並行，可利用分支。

• 典型情景二：在做系統整合工作之前，需要凍結程式碼，防止開發人員在整合工作期間，隨意提交新的修改，影響整合工作。如果整合的時間比較長的話，必然會影響軟體開發工作的效率。

• 解決方法：

        為了使整合工作不阻滯開發工作，可使用分支。

5.分支典型應用三：管理變體

• 變體（Variant）是同一類軟體產品，它們有很多相同之處，卻又有所區別。

• 變體之間雖然相似，但不可能進行合併。

• 產生變體的最常見原因包括：

1.  因支援不同的作業系統而產生變體

    例如同一個軟體產品在Windows系統上和Unix系統上的不同版本。兩種版本所呼叫的作業系統介面以及開發環境都有很大差別。

     2. 因客戶定製而產生變體

    對於同一種軟體產品，不同的客戶提出的要求有區別，例如財務管理系統，不同客戶的財務管理制度、管理流程是有區別的，因此需要特殊定製，從而產生變體。

    3. 因不同的功能集產生變體       

   軟體不同的變體是針對不同的消費群體的需要而製作的。例如Windows Vista有七個版本：家庭類的初學者版、家庭基礎版、家庭標準版和家庭終極版；商務類的小企業版、專業版和企業版。

• 用分支支援變體的第一種方法：為每一個變體建立一個分支。

• 第二種方法：為變體不同的版本建立不同的分支。

6. 關注主線的演進

• 不管版本樹的分支有多少，都應該有一條主線，作為開發工作的主流，集中精力於主線的演進，其它分支以主線為基礎進行開發。

• 例如，當軟體存在多個變體時，不能不分主次地為每一個變體建立一個分支，各自獨立開發。

錯誤的版本樹形狀


正確的版本樹形狀

有問題的版本演化策略

• 該策略存在的問題：

1.  分支層數太深，可能會超出版本控制工具的分支層數範圍。
2. 檔案的版本演化歷史資訊複雜，分佈在不同的分支中。
3. 開發人員需要經常更換分支，容易出錯。

7. 分支管理要點

• 分支不能隨意建立，必須有所規劃，適當管理。

• 分支管理要注意以下幾點：

1.  分支要有明確的目的。分支應有一個名字，簡略說明分支的目的。
2. 分支要規劃好何時建立，從何處建立。
3.  分支要規劃好是否合併？合併到哪裡？分支上所有的工作成果都要合併，還是有選擇地合併？
4. 分支要規劃相關角色和許可權：誰有權讀取分支上的內容或向分支提交？分支的合併及分支上的整合工作由誰負責？誰負責建立、刪除和重新命名分支？
5. 分支的規劃要全盤考慮，看版本樹的整體圖景，而不要只關注手邊的工作。

第七節 變更管理

7.1 影響變更控制方法的因素
7.2 嚴格的變更控制流程
7.3 任務管理

7.1 影響變更控制方法的因素

• 對軟體原有配置項的改變叫做變更（change）。對變更必須進行有效的管理，避免其產生負面影響。

• 變更管理（控制）方法主要受以下因素影響：變更的規模、變更的影響面、變更發生的時間、開發過程模型、研發團隊的規模。

1.變更規模對變更控制的影響

• 有些變更可以較快完成，且規模較小，比如缺陷的修復，對功能進行的少量增強。對於這類比較小的，數量又比較多的變更，可採用缺陷跟蹤的方式來跟蹤和管理。

• 有些變更需要不少的人力和時間，對專案的進度和預算都有影響，對這樣的大型變更，就需要更嚴格的控制和企業高層的介入。

2.變更影響面對變更控制的影響

• 有些變更只會影響到產品的區域性，而有些變更則可能會產生廣泛的影響，例如公用函式庫的變化。

• 對於有廣泛影響的變更，必須有更為嚴格的控制，變更前要廣泛徵求意見，認真評估，變更後要通知大家，發生了什麼改變。

3.變更發生時間對變更控制的影響

• 越到專案後期，變更的代價就越大，因此對變更的控制就越嚴格，也越不容易接受變更。

• 在專案末期，通常只會接受缺陷修復和小的功能增強。

4.過程模型對變更控制的影響

• 在瀑布模型中，專案各階段的工作是順序執行下來的，前一階段的工作成果是後一階段工作的輸入，它要求前一階段的工作成果一旦確定下來後，儘量不發生變化，否則對後續工作的影響太大。

• 在瀑布模型中，要更嚴格地控制變更。而在迭代型/適應型過程模型中，可以有更多的變更。

• 迭代過程模型的核心思想是“儘早反饋”。

• 迭代過程模型把一個大專案在時間軸上劃分為若干個小週期，每個小週期稱為一個迭代（Iteration）。幾乎每次迭代結束時，都會產生一個可見的成果（可執行的軟體包）。使用者可對該成果進行評估，提出修改意見。研發團隊也可以在短短的一個迭代週期內就發現需求、設計等方面的問題，從而可在下一個迭代中進行變更。

• 迭代過程模型對待變更的態度更為現實、更為積極，在採用迭代式開發的專案中，變更更為頻繁。

• 通常在一次迭代開始之初，研發團隊討論確定本次迭代要進行哪些變更。但在每次迭代進行過程中，一般不會接受大的變更，因為每次迭代應該有相對確定的任務。

5.研發團隊規模對變更控制的影響

• 在小型團隊裡，當變更發生時，人員之間可以採用隨意的溝通方式。但在規模較大的團隊中，可能需要採取一些正規的方式解決溝通和協作問題，使變更得到控制，例如建立變更控制委員會，將變更請求條目的狀態變化自動傳送郵件通知相關人員。

7.2 嚴格的變更控制過程

變更請求

變更評估

變更審批

根據評估結果對變更作出決策：

• 直接實現變更

• 掛起或延遲變更

• 拒絕變更

變更實現

7.3 任務管理

• 任務（Task）是由軟體專案團隊人員所執行的一個活動，它生成或改變配置項。

• 變更是通過執行任務完成的。

7.3.1 任務流程的設定
7.3.2 任務流程中的許可權設定
7.3.3 建立任務間的關係
7.3.4 自動郵件通知
7.3.5 任務資訊的設定
7.3.6 任務資料對專案管理的支援

7.3.1 任務流程的設定

• 為了控制變更，保證任務結果的質量，任務需要按照一定的流程執行。

• 優秀的配置管理工具可以對任務流程進行定製，如ClearQuest、JIRA。

• 任務流程可使用狀態模型圖或狀態轉移矩陣表示。

                        典型的缺陷任務（缺陷跟蹤）流程的狀態模型圖

                       典型的缺陷任務（缺陷跟蹤）流程的狀態轉移矩陣

                                              典型的新任務流程的狀態模型圖

7.3.2 任務流程中的許可權設定

• 在任務流程中，不同的人員角色具有不同的職責和許可權。

• 配置管理工具應能夠設定在任務的每個狀態下可由那些角色執行哪些動作。

• 任務流程涉及的常見的人員角色包括專案管理人員、開發人員、開發小組長、測試人員、測試小組長、整合人員。

• 專案管理者包括專案經理及其他變更控制委員會成員，其許可權包括建立、取消、分配任務，使任務處於新建、已取消、已分配等狀態。

• 開發小組負責人的許可權是在任務處於已分配狀態時根據需要對任務進行重分配或取消不必要的任務；在任務處於評審狀態時批准或駁回任務已完成的修改；對處於已推遲和正在工作狀態中的任務，可根據小組人員安排情況，在組內重新分配。

• 開發人員的許可權是：在任務處於已分配狀態時，接受任務，使之處於工作狀態；如果認為任務無效（例如缺陷不能重現或與其它缺陷報告重複），可以把任務退回；在任務完成後可提出評審申請。

• 測試負責人的許可權包括：當認為缺陷確實是無效時，可把缺陷取消；對測試人員已驗證的缺陷進行審查，如果沒有問題可最終關閉缺陷任務，否則可打回測試結果，要求測試人員重新驗證。

• 測試人員的許可權包括：對於被退回的缺陷任務，可對缺陷報告進行補充和澄清，再重新分配給開發人員；對開發人員已解決的缺陷進行測試驗證，如果通過將缺陷置於已驗證狀態，如果不通過則駁回該缺陷的修改結果。

• 整合人員的許可權是：如果由開發人員提交的任務結果導致整合失敗，可駁回任務結果，由開發人員繼續完善；如果整合成功，可將任務標記為“已整合”狀態。

7.3.3 建立任務間的關係

• 父子關係。將一個複雜的任務分解為多個子任務，由相同或不同的人員去完成。

• 配置管理工具應該建立父任務和子任務之間的關聯性，並可自動在它們之間同步，例如只有當所有子任務都已完成並通過驗證，父任務才能通過驗證。

• 依賴關係。任務之間必須按照一定的順序去執行，一個任務開始或完成後，另一個任務才能開始或完成。

• 重複關係。重複關係一般出現在缺陷修復任務之間。由不同的人員報告的缺陷實際上是一個問題，為了避免後續開發人員重複分析處理同一個問題，應在這些缺陷任務之間建立重複關係。開發人員只要處理其中一個任務，其它任務就會自動同步地發生狀態變化。

7.3.4 自動郵件通知

• 當任務的狀態發生改變後（例如一個任務被分配給了一個開發人員），相關人員應及時得到通知。自動郵件通知是最常用的一種方式。

• 在配置管理工具中實現自動郵件通知一般需要以下步驟：

• （1）設定郵件伺服器。

  一般應使用區域網中的郵件伺服器。
  需設定郵件伺服器的名稱、SMTP埠等資訊。

• （2）設定郵件通知方案。

  郵件通知方案規定了當任務流程中一個動作發生時，應向哪些使用者傳送郵件。
  在配置管理工具中，應該可以新建或修改郵件通知方案。

• （3）把郵件通知方案賦給專案。一個郵件通知方案可用於多個專案。

                                                     JIRA的郵件通知方案編輯介面

7.3.5 任務資訊設定

• 正確地設定任務資訊不僅有利於變更控制，而且可以為專案管理和過程改進提供豐富的資料。

• 優秀的配置管理工具（如ClearQuest、JIRA）可以對任務資訊進行定製。

• 任務資訊通常包括描述資訊、範圍資訊、人員資訊、附加資訊等。

• （1）任務描述資訊

1.  任務標誌：任務的唯一識別符號；
2. 任務標題：簡單描述任務的單行文字；
3. 任務詳細描述：詳細地描述任務的細節，是任務執行者主要的依據；
4. 優先順序：確定任務執行的優先順序；
5. 嚴重程度：通常用於缺陷任務，表示缺陷對系統的影響程度，例如可分四級：1-Fatal, 2-Critical, 3-Major, 4-Minor；
6. 影響：任務影響的一些活動；
7. 狀態：任務當前在處理流程中所處的狀態；

• （2）範圍資訊

1.  產品：標明任務屬於哪個產品。
2. 版本：標明任務屬於產品的哪個發行版本；
3. 模組：標明任務屬於產品中的哪個模組；
4. 功能：主要用於缺陷任務，說明缺陷是由哪個功能引起的。

•  （3）人員資訊

1.  執行者：任務在當前狀態下的執行者；
2. 報告者：任務的提出者。

• （4）附加資訊

1.  估計花費時間：估計完成該任務所花費的時間，單位為小時；
2.  實際花費時間：完成該任務所實際花費的時間，單位為小時；
3. 缺陷發現方式：如測試、評審、使用者使用發現等。
4.  缺陷引入階段；
5.  缺陷原因分析；
6. 附件：有利於任務執行的一些資料，如錯誤發生時的螢幕截圖、日誌檔案等。

7.3.6 任務資料對專案管理的支援

• 專案是通過執行所有的任務完成的，所以從配置管理系統所記錄下的任務資訊中，可以提取出豐富的支援專案管理的資料度量，例如：

• 有關專案進度的度量：

1.  專案當前完成的功能數和總功能數的比例；
2. 當前已解決缺陷數和未解決缺陷數的比例；
3. 每週新發現的缺陷數趨勢圖；
4. 未完成的任務趨勢圖，按周統計。

• 有關產品質量的度量：

1.  缺陷模組分佈，反映各模組的質量；
2. 缺陷嚴重級別分佈，反映產品的總體質量；

• 有關工作效率的度量：

1.  缺陷發現方法分佈，反映測試、評審工作的效率；
2. 任務在特定狀態下停留（老化）的時間分佈