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

? pure-systems GmbH

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

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

配置管理系統的誤用及帶來的問題

首先，我將列出大家在產品線實施配置管理時可能會犯的錯誤，即把它作為一個變異性和變體管理的系統來使用。通常情況下，配置管理系統（又稱版本控制系統）提供一個被稱為分支的概念。分支意味著創建一組工件的副本并且隨后會對其進行獨立于原件的修改。分支有許多適當的用途（我們將在后面講到）和一個相當不恰當的用途：將分支作為資產復用管理的核心。

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

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

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

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

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

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

• Q3--共享和非共享的資產與變更集

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

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

• Q4--它不只發生在文件上

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

圖1?pure-systems

• 關于誤用的結論

總結一下，除非版本管理中工件顆粒度與變體顆粒度基本一致，否則版本管理中的分支并不利于表達變體。因此，無論您的版本管理系統的供應商多么強調其處理變化的能力，您都需要注意顆粒度是否匹配。并且在工件是文件的情況下，出現顆粒度不匹配的情況幾乎是不可避免的。但是，也請不要誤會我的意思：您必須使用適當的版本管理來跟蹤您的工件在其生命周期內的變化。只是不要將變體和變體管理混在其中。變體管理是一個獨立的、正交的維度，表達了在某一特定時間點可用于和被用于變體的內容。

正確使用產品系列的配置管理系統

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

圖2?pure-systems

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

總結

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

作者：Danilo Beuche

翻譯：經緯恒潤