摘要： 軟件配置管理包括對代碼、文檔、數(shù)據(jù)等的管理，其優(yōu)劣受限于項目成員的實際操作。開發(fā)人員對于工作區(qū)如何使用；成員之間的代碼是不是可以及時更新與同步；怎樣使用分支，如何進行變更合并，才能減少物理空間浪費和事件延遲。這些問題在實際的項目開發(fā)中往往被忽視，亦或團隊并沒有對成員行為作細節(jié)的規(guī)范，因而許多軟件項目出現(xiàn)了工期推遲或代碼質量不高等問題。為此提出了一系列管理措施，通過優(yōu)化軟件配置管理規(guī)范項目各成員的行為，以保證高效的軟件配置管理的實施。

關鍵詞： 軟件配置管理； 工作區(qū)； 代碼； 分支與合并； 過程及規(guī)范

中圖分類號：TP311.5 文獻標志碼：A 文章編號：1006-8228(2012)10-67-03

引言

軟件配置管理（SCM，Software Configuration Management）是軟件項目中一個非常重要的活動，存在于整個軟件項目周期當中，管理項目的所有代碼、數(shù)據(jù)、文檔等，以保證軟件項目過程的可控，變更歷史可追溯。本文從六個基本角度：工作區(qū)、開發(fā)線、分支、合并、編譯以及過程規(guī)范，探討軟件配置管理優(yōu)化的方案。希望項目成員能夠以優(yōu)化自己的日常工作為起點，與團隊一起共同提高軟件項目的配置管理水平。

1 工作區(qū)優(yōu)化

工作區(qū)是開發(fā)者進行代碼開發(fā)、測試、變異的特定分配區(qū)域，幾乎每種SCM系統(tǒng)都存在“工作區(qū)”這個概念，它界定了開發(fā)人員的工作領域，避免開發(fā)人員之間的工作相互影響。

1.1 不共享工作區(qū)

為了便于管理，工作區(qū)應該遵循分離原則。工作區(qū)的共享，實質上顯示了開發(fā)人員工作空間的物理條件的共享性，這樣一來，某個開發(fā)人員的修改，就會導致共享此工作區(qū)的其他人員工作的混亂。物理空間并非高價之物，不要為了節(jié)省磁盤空間而浪費時間，在軟件項目中，分秒必爭，時間不可浪費。

1.2 禁止工作區(qū)外開發(fā)

背著SCM進行暗地操作，其歷史的追蹤將成為不可能。為了開發(fā)團隊的交流，每個開發(fā)者的工作區(qū)內容，可以被其他成員查看，而不允許其他成員修改。如果開發(fā)人員在工作區(qū)外部進行開發(fā)，其工作不能與團隊共享，且修改歷史不能被跟蹤，這將沒有辦法在發(fā)生問題時回滾到之前正確的狀態(tài)，造成工作的徒勞。

1.3 避免由外至內的影響

對于自己工作區(qū)內的文件，應該極力避免非意志性的文件更改。主要是，不受SCM系統(tǒng)管理的外部物理空間發(fā)生的活動，引起了SCM工作區(qū)內的文件的更改。例如，軟件的編譯行為，可能會增加SCM控制區(qū)內文件。為了保證項目受控工作區(qū)域的文件穩(wěn)定性，應避免工作區(qū)外部行為對內部文件的增刪改。

1.4 同步項目庫代碼

開發(fā)人員check-in代碼時，需先將自己的工作區(qū)與版本庫進行同步，在沒有沖突的情況下進行本地修改的check-in，當有較大沖突時，需要配置管理者對沖突進行手動修正。如果可以減少這樣的沖突，及時將工作區(qū)本地版本與服務器同步，保持SCM管理下的代碼最新，可以減少代碼最終提交時的尚待解決的沖突，避免延遲工期。

1.5 及時check-in

當多名開發(fā)人員協(xié)同開發(fā)時，開發(fā)告一段落，開發(fā)人員需要通過check-in代碼去告知其他開發(fā)者自己的變更，而及時的check-in可以保證其他人員能夠及時得到庫內的新版本，減少沖突的出現(xiàn)。當然配置管理組，也需要建立支持頻繁變更的機制，避免對代碼變更過于復雜保守的評價。變更審查的時間越久，就會造成越大的項目時間的浪費。

2 代碼行為優(yōu)化

代碼在配置管理的過程中會分成不同的版本，不斷更新完善，最后發(fā)布。代碼的管理是軟件項目配置管理的重要工作部分。

2.1 制定代碼策略

代碼策略指對于代碼正確使用的方法、如何審定check-in的代碼，而確立的規(guī)則，這些策略將是代碼部分管理的重要手冊。代碼變更如何進行書面化描述，怎樣進行編譯、測試，check-in后的代碼安定性預期值等，都需要在規(guī)則中進行明確規(guī)定。沒有規(guī)則化的代碼開發(fā)，從軟件配置管理的角度而言，可以說等同于失去可控性。

2.2 設立開發(fā)控制責任人

有了代碼策略，也不能排除規(guī)則不適用或者含糊不清的特殊情況，為了解決這些特殊情況，開發(fā)者可以通過控制人員得到統(tǒng)一的解決方法。設定開發(fā)控制責任者，使其承擔特定部分代碼的責任以及規(guī)則把握，避免開發(fā)者遇到問題時擅自解決，并將遇到的特殊情況書面化，以便項目組積累經(jīng)驗，為后續(xù)開發(fā)奠定基礎。

2.3 使用主線開發(fā)模式

如圖1所示的基于主線的開發(fā)模型，可以看到從主線分出了幾條發(fā)布線（\"ver1\"、\"ver2\"、\"ver3\"）與開發(fā)線（\"projA\"、\"projB\"、\"projC\"）。開發(fā)者在主線與開發(fā)線上進行開發(fā)活動，發(fā)布線用于測試以及bug修正。發(fā)布線與開發(fā)線上進行的變更，最終需合并到主線中。主線開發(fā)，支持并行開發(fā)，大大減少軟件產(chǎn)品在其生存周期成熟之前的管理開銷，并且主線模型可以避免代碼凍結，使項目順利進行。

3 分支優(yōu)化方案探討

分支功能是軟件配置管理下最容易產(chǎn)生問題的部分。不同的軟件配置管理方案，對分支進行不同方式的支持，或者可以說，根據(jù)不同的規(guī)則，分支機能也得到不同程度的活用。

3.1 需用才用

所有分支的變動幾乎都會引起項目人員的工作量的增加（編譯工作、代碼的變更傳達，分支合并等）。增加分支同時，需要充分意識到對項目工作量的增加，減少不必要的分支的增加，并盡可能避免在分支上再建分支，以降低對項目進度的影響。

3.2 傳遞靠分支不靠備份

當開發(fā)線全部或者一部分需要轉交時，不要進行復制傳遞。復制傳遞需要將一條生產(chǎn)線上的全部文件都復制到新位置，作為新的文件在新的開發(fā)分支上進行使用。由于復制之后文件的增加，不僅增加了物理空間的負擔，同時對于相同的文件，SCM系統(tǒng)仍需要管理這些新分支的“新”實體以及他們的歷史記錄，這將增大配置管理的復雜度。

3.3 不同原則不同分支

如果開發(fā)人員遵循著不同的檢入/檢出原則，則應該在不同分支上進行開發(fā)。例如：負責軟件發(fā)布的小組，要求進行嚴密的測試之后才可以進行check-in；而開發(fā)組需要及時同步代碼版本，只要進行簡單的測試就可以check-in。像這樣依據(jù)完全不同的工作原則時，分支開發(fā)是必須的。

3.4 不到必要時不創(chuàng)建分支

不談建立分支的物理消耗，為了最小化分支之間變更傳遞的復雜性，應將分支建立盡可能向后推延。例如，過早為新功能建立發(fā)布分支，該分支上新功能的測試以及bug修正不得不同時向主線上合并，這是時間和工作量上的浪費。發(fā)布分支建立前，在開發(fā)主線上進行測試與bug修正的話，分支之間傳遞的變更信息將會大大減少，可以節(jié)省時間與精力。

3.5 以分支緩和凍結

有時，項目需要對代碼進行凍結以便進行測試工作，而這對于開發(fā)者而言，在測試完成之前，開發(fā)產(chǎn)生的變更無法與項目代碼進行整合。這種情況下，為了使開發(fā)人員的工作得以正常進行，應該在代碼凍結之前盡可能早地建立新分支。

4 合并優(yōu)化方案探討

合并指的是某一分支的變更向目的分支的更新整合操作。這是我們不得不直面的SCM中的一個重要且普遍的問題，而這并不是一個簡單的工作。

4.1 變更合并相似分支

分支時間越長，沖突就越多，合并開銷就越大。對于一次變更，與其與經(jīng)過較多修改的分支進行合并，不如與變化不大的分支合并來的容易。例如，主線模型中，應該在發(fā)布分支上進行bug修正等操作，功能穩(wěn)定后合并到開發(fā)主干上。若在主線上進行bug修正，合并時原本不需要的修改可能也會傳給發(fā)布分支，而這些無關變更可能造成開發(fā)人員工作混亂。

4.2 勤于合并

要盡量頻繁地進行合并。及時合并處于穩(wěn)定點的分支，讓自己的修改盡快被其他相關開發(fā)人員得知，這可以有效地減少開發(fā)成員之間的代碼沖突。同時變更的合并，趕早不趕晚，及早進行合并，以減少延遲合并可能產(chǎn)生的沖突。

4.3 設立合并責任人

開發(fā)修改的變更合并很大可能會存在沖突，如果由恰當?shù)拈_發(fā)人員進行解決的話，那么沖突所帶來的負擔便會大大減輕?？赡軗魏喜⒇熑稳说拈_發(fā)者包括：(a)目標分支的所有者；(b)執(zhí)行合并的開發(fā)者；(c)a、b之外的開發(fā)者。與c相比，a、b更適合作為合并的負責人員。

5 編譯優(yōu)化方案探討

編譯即是通過使用眾多源代碼文件，生成可以使用的軟件產(chǎn)品的過程。

5.1 源碼+工具=軟件產(chǎn)品

源文件以及編譯工具是編譯的重要組成部分。如果編譯需要通過腳本進行自動執(zhí)行，或者手動執(zhí)行時，那么安裝使用的順序等應落實文本化。且操作系統(tǒng)、編譯器、庫文件、動態(tài)鏈接庫、編譯文件以及各項規(guī)范等，所有編譯涉及到的文件都應該進行文本描述，以保證通過正確的相同的順序，相同的文件，相同的編譯器，產(chǎn)生相同的結果。

5.2 check-in所有源

為了保證不論誰在哪里按照相同順序都可以編譯得到同樣的結果，編譯活動所需源文件需要無遺漏地進行check-in。Makefile、安裝腳本、編譯腳本、編譯手冊、規(guī)范等，這些都是編譯不可少的文件。應該時刻銘記：源碼+工具=軟件產(chǎn)品。

5.3 編譯與源庫分離

將編譯生成的目標代碼文件轉移到獨立或者外部目錄下，與版本庫目錄中的文件進行隔離，避免目標代碼文件混于配置管理版本庫中造成混亂。這種分離，將軟件配置管理簡化在源文件層級，減少SCM系統(tǒng)對冗余文件的管理負擔。

5.4 相同工具編譯

開發(fā)者、測試人員、發(fā)布人員，所有的項目成員應該保證使用同樣的編譯工具，以便相同操作順序產(chǎn)生相同結果，避免問題情景不能重現(xiàn)，減少找不到問題根本而造成的時間浪費。

5.5 頻繁編譯

即使項目時間充裕，項目所有分支部分的編譯以及回歸測試也應該定期、頻繁地進行，以保證開發(fā)主線、各分支的正確性。伴隨回歸測試頻繁進行的全項目編譯，具有兩個優(yōu)勢：一是明確check-in之后項目集成可能出現(xiàn)的問題；二是通過編譯得到可使用的鏈接庫。

5.6 存檔編譯結果

在編譯正確執(zhí)行并產(chǎn)生預想結果時，所經(jīng)過的正確操作以及操作順序，以及源文件、編譯工具與操作系統(tǒng)版本信息、編譯工具輸出、被編譯項目、測試結果等，連同編譯日志一起應及時存檔。例如：編譯產(chǎn)生的中間件轉交使用時，可能需要重編譯才能使用，而編譯存檔將避免在重編譯時遇到相同問題。編譯存檔是經(jīng)驗的積累，可減少重復工作，節(jié)約時間。

6 SCM過程探討

6.1 追溯目錄變更

開發(fā)過程中各類別的文件都具有自己的變更歷史，而文件的變更只有在特定階段，相關文件集合中，才具有實際意義。例如：foo.c文件，在某一時期發(fā)生變更的同時，還有哪些文件發(fā)生了變更·為了更好地回答這個問題，就需要目錄的變更跟蹤，不是針對單一文件，而是對相關文件集合的跟蹤。選擇可以追蹤目錄的SCM系統(tǒng)也是SCM的首要任務。

6.2 關注相關合并

目錄變更跟蹤的一個優(yōu)勢在于可以很明顯看出分支之間邏輯上的變更蹤跡。哪些變更集合進行了合并，哪些處于保留狀態(tài)，哪些是合并分支，哪些是目標分支，通過對目錄變更的跟蹤，可以明確bug A的修正是不是影響發(fā)布分支X，是不是被合并到了測試分支Y上。SCM系統(tǒng)的此功能，可以提高項目變更的可見性與邏輯性。

6.3 設立配置項責任人

SCM過程所涉及的管理項包括：規(guī)則規(guī)范、產(chǎn)品、構件、代碼、分支、任務等，需要項目組針對所有項設立責任人，以規(guī)范所有單項的正確執(zhí)行，核實所有的變更活動，在有沖突之時進行決斷，避免項目成員各自為營，給好不容易建立的SCM體系效果減分。

6.4 使用有效文檔

項目過程中產(chǎn)生的文檔可能伴隨項目進行而更新，同樣需要SCM對其進行歷史管理。有效文檔是項目可用的最新的版本，應保證它們的可訪問性，無論是從哪種工作開發(fā)環(huán)境，甚至根據(jù)需要在家里，都可以訪問這些文檔。對于項目的安裝使用說明文件等，涉及保證成員相同操作的文件，需要保證其變更審核的簡易性，以便盡快使這些文件的更新得到應用，以保證項目成員統(tǒng)一規(guī)范的行為活動。

7 結束語

基于軟件開發(fā)項目的大規(guī)模性、需求多變更性，以及多技術人員開發(fā)、高質量化、費用控制等方面的必要性，軟件配置管理成為了保證項目高效順利進行的一個重要課題。借助于良好的軟件配置管理工具，加之規(guī)范的項目開發(fā)行為，才會有高效配置管理。

本文著眼于日常開發(fā)人員的工作，從配置管理伊始到最后項目結束，乃至后期的軟件維護等，都離不開軟件配置管理。從創(chuàng)建分支，到變更合并，再到項目文檔體系，雖然都是我們每天面對的習以為常的事情，卻更需要多加注意，從小處杜絕配置管理上的物理空間浪費和管理復雜化，從而在有效的配置管理的護航下，順利實現(xiàn)項目按時、保質、保量的完成。

當然以上所提及的問題并不是全部，如果想要更完美地實現(xiàn)配置管理，還需要我們在自己的項目開發(fā)過程中不斷發(fā)現(xiàn)問題，不斷尋找最佳解決方案，不斷總結經(jīng)驗，以成就成功的軟件項目。

參考文獻：[1] 嚴曉光，王小剛，陳曼煜.軟件配置管理的問題、目的、層次和策略[J].

計算機工程與科學，2009.5:90-92，101

[2] 朱寅非.淺析配置管理在軟件開發(fā)中的作用[J].南京廣播電視大學學報，2010.4:93-96

[3] 孟顯英.企業(yè)中實施軟件配置管理過程中的誤區(qū)[J].科技信息，2010.21:588

[4] 勃克扎著，黃明成譯.軟件配置管理模式[M].中國電力出版社，2004.