深入產(chǎn)品線的配置管理

“大家好，這是【產(chǎn)品線工程（PLE）專題】更新的第五篇，上一篇我們介紹了‘特征模型和特征-這是什么’，這一篇我們介紹‘深入產(chǎn)品線的配置管理’”

? pure-systems GmbH

如果您目前已經(jīng)閱讀了我們所有的白皮書，那么您應該了解了特征、特征模型以及變體都不是“版本”。但是這里仍然有一些并未提及的事情：產(chǎn)品線的配置管理。接下來的這篇文章便是就該話題進行討論。

產(chǎn)品線的配置管理是一件復雜的事情嗎？這是肯定的！產(chǎn)品線的配置管理必須要復雜嗎？并不完全是！可以說，單個系統(tǒng)開發(fā)的配置管理和產(chǎn)品線開發(fā)的配置管理之間沒有(重要的)區(qū)別，除非您做錯了。可能您會對此表示懷疑，那么針對這個觀點，我們將會進行更深入的探討。

配置管理系統(tǒng)的誤用及帶來的問題

首先，我將列出大家在產(chǎn)品線實施配置管理時可能會犯的錯誤，即把它作為一個變異性和變體管理的系統(tǒng)來使用。通常情況下，配置管理系統(tǒng)（又稱版本控制系統(tǒng)）提供一個被稱為分支的概念。分支意味著創(chuàng)建一組工件的副本并且隨后會對其進行獨立于原件的修改。分支有許多適當?shù)挠猛荆ㄎ覀儗⒃诤竺嬷v到）和一個相當不恰當?shù)挠猛荆簩⒎种ё鳛橘Y產(chǎn)復用管理的核心。

如果采用如下方式處理變體，例如首先創(chuàng)建分支，然后使用分支區(qū)分不同的產(chǎn)品。那么在大多數(shù)情況下，與其他的復用方式相比，這種方式會出現(xiàn)（不必要的）開銷，這是因為通常有分支的工件（簡單的，我們假設(shè)針對單個文件的分支）不會被完全修改，并且在原始和分支副本之間存在一定數(shù)量（通常相當大的）相同部分。

• Q1--您怎么知道什么被復用了，以及在哪里被復用了？

設(shè)想一個場景，我們在分支或者原始流中發(fā)現(xiàn)了一個問題，（我們假定是在原始版本中發(fā)現(xiàn)的）。我們完成了修復工作并且遞交到版本管理系統(tǒng)中。目前為止，看起來一切安好?，F(xiàn)在，我們需要對這個分支做些事情。首先，我們注意到：分支的工件正在某些產(chǎn)品中使用，那么我們必須對其進行修復。有些版本管理系統(tǒng)支持您在發(fā)生變化時，在分支中找到相關(guān)的工件。目前看起來不錯。在文件的某些部分發(fā)現(xiàn)了修復，這些部分在原始文件和分支中看起來都是一樣的，似乎很容易簡單地復制修復。不過雖然看起來這不是個問題，但它肯定會引起其他問題。

• Q2--您怎么知道應用的修正是正確的？

等一下! 您怎么知道在分支中文件的這一部分內(nèi)容是被允許修改的呢？變體的受管理粒度在文件中，因此，無論是對于版本管理系統(tǒng)還是對于人員，都沒有簡單的方法去了解分別屬于原始和分支文件的多個相同實體（例如，文件中的行）是否應該相同（不是實際變體的一部分，因此應該共享），或者某些實體是否實際屬于變體（如分支時所預期的那樣）且不得更改。

我們可以舉一個例子，例如配置一個用于設(shè)置緩存區(qū)大小的常量參數(shù)。如果該參數(shù)同時在源算法和分支算法中使用，那么在源算法的實現(xiàn)中的修改并不意味著在分支的算法中進行修改，分支中甚至可能不允許修改。因此，即便從技術(shù)上，在版本管理中應用某修復程序不會顯示產(chǎn)生沖突，您也必須對該修復程序的哪個部分可以應用于分支工件進行檢查。在擁有恰當?shù)淖詣踊瘻y試套件的情況下，您必須對包含合并工件的所有產(chǎn)品進行測試，以確保沒有產(chǎn)品受到損害。但在其他所有情況下（對于某些領(lǐng)域的自動化測試套件是不可能的），基本上只能依靠工程師的經(jīng)驗。

• Q3--共享和非共享的資產(chǎn)與變更集

m如果分支的工件基本上代表了一個變體，并且（幾乎）不包含任何共享的代碼，那么這個問題的討論就不存在了。這意味著變體在文件的顆粒度上被適當?shù)胤庋b了。在這種情況下，一個文件在原始副本和分支副本之間或者被共享，或者不被共享。如果所有的文件都如此，那么您只須處理包含了共享文件和非共享文件的變更集即可，但必須把它們分成只與共享文件有關(guān)的變更集和針對單一分支的變更集。

對于包含共享文件的變更集，必須對所有共享文件的實例進行變更。但是如果您后來從以前的分支副本中創(chuàng)建了一個新的分支，該分支副本與原始的分支副本共享，但沒有與原始副本共享，那么情況就會變得復雜。再強調(diào)一次，在版本控制系統(tǒng)中跟蹤處理這種情況會很復雜。

• Q4--它不只發(fā)生在文件上

到目前為止，我一直在談?wù)摗耙粋€文件”，但實際上，可能會存在成百上千的問題件。而且，因為對于每一個變化，您都必須對每個分支進行同樣的處理，所以隨著分支數(shù)量的增加，工作量也會急劇增加。雖然針對少量共享工件和少量的分支而言是可行的，但是少量的共享工件限制了可重用工件的數(shù)量，而少量的分支則限制了變體的數(shù)量。我們可以通過一張圖看到其復雜性。圖1顯示了一個典型的（簡化的）來自版本控制系統(tǒng)的分支/合并日志（時間從左到右進行）。使用典型的“分支&合并”策略，即創(chuàng)建現(xiàn)有系統(tǒng)的克隆，之后通過獨立維護的方式來管理七個產(chǎn)品（P1-P7）。顯然，使所有分支實例保持變化同步是一項相當大的任務(wù)。由于進行合并需要工作量，因此在大多數(shù)情況下，只有“成對的”合并發(fā)生，即從另一個產(chǎn)品中直接挑選一些部件，從而導致系統(tǒng)性的復用卻看起來互不相同。

圖1?pure-systems

• 關(guān)于誤用的結(jié)論

總結(jié)一下，除非版本管理中工件顆粒度與變體顆粒度基本一致，否則版本管理中的分支并不利于表達變體。因此，無論您的版本管理系統(tǒng)的供應商多么強調(diào)其處理變化的能力，您都需要注意顆粒度是否匹配。并且在工件是文件的情況下，出現(xiàn)顆粒度不匹配的情況幾乎是不可避免的。但是，也請不要誤會我的意思：您必須使用適當?shù)陌姹竟芾韥砀櫮墓ぜ谄渖芷趦?nèi)的變化。只是不要將變體和變體管理混在其中。變體管理是一個獨立的、正交的維度，表達了在某一特定時間點可用于和被用于變體的內(nèi)容。

正確使用產(chǎn)品系列的配置管理系統(tǒng)

如果您現(xiàn)在想知道哪些分支在產(chǎn)品線開發(fā)中是有用的，可以這樣描述它們——在單個產(chǎn)品開發(fā)中，分支只適用于兩件事：將獨立開發(fā)活動與主開發(fā)分支（通常稱為“功能分支”）進行短期解耦，以及將（即將發(fā)布的）版本與主分支上正在進行的更改（通常稱為“發(fā)布分支”）解耦。這兩個概念的描述可以在一些版本管理的電子書中看到（描述大多數(shù)獨立于版本，只需要將“trunk”替換為“主開發(fā)分支”即可）。應用這些概念可以繪制一個相對于圖1而言更加清晰和美觀的圖（見圖2）。主開發(fā)流上方的分支（在下圖中稱為"集成"）表示為發(fā)布創(chuàng)建的分支，下面的分支用于開發(fā)新功能。通常，分支要短得多，合并主要從開發(fā)分支到主（集成）開發(fā)流，很少從（或到）發(fā)布分支。

圖2?pure-systems

這種方法不僅使畫面更美觀，也使真正的復用變得更容易實現(xiàn)。在圖中，您看到的是變體（V1-V4），而不是產(chǎn)品，它們來自同一個共同的基礎(chǔ)。從共享庫中實際派生變體這一動作將作為獨立活動執(zhí)行，且通常通過配置或使用適當?shù)目勺冃院妥凅w管理工具（如 pure::variants）來實現(xiàn)。關(guān)鍵點在于此派生/實例化活動是在受版本控制的工件之上完成的，因此版本控制系統(tǒng)可用于記錄實例，但不提供變體點機制。

總結(jié)

這讓我回到了我最初的主張：如果可變性和變體的表示沒有通過版本管理來實現(xiàn)（通過版本管理實現(xiàn)是個好主意，如上文），那么當涉及到產(chǎn)品線時，除了性能和可擴展性（由于更多的用戶和更多的變化）之外，版本管理沒有什么特別之處。

作者：Danilo Beuche

翻譯：經(jīng)緯恒潤