軟件發(fā)行管理（上）
   
    上一篇講了發(fā)行管理的一些基本理論，最主要最根本的一點就是不要對發(fā)行的內(nèi)容失去控制。在這個基礎(chǔ)上逐步加強對發(fā)行節(jié)奏的協(xié)調(diào)，可以形成良好的軟件發(fā)行管理制度，提高軟件發(fā)行能力。下面要說的是發(fā)行中的一些細節(jié)。

    在一個軟件的生命周期中，一般會有多次發(fā)行，尤其對于迭代開發(fā)的軟件更是這樣。每隔一段時間，生產(chǎn)商就會發(fā)行一個主要版本，其中包含大量功能改進或新增功 能。同時，在每個主要版本發(fā)行的間隔中，也會發(fā)行一些對當前用戶使用版本的補丁。這種情況是由軟件本身的性質(zhì)決定的。對于實體的產(chǎn)品（如汽車），當發(fā)現(xiàn)設(shè) 計缺陷時必須要“召回”；而對于非實體的、形式的軟件產(chǎn)品，當發(fā)現(xiàn)缺陷時，就需要發(fā)行一個更正的補丁。實際上，軟件的主要版本和補丁版本往往是同時開發(fā)/ 修改的。版本管理和發(fā)行管理使用這種并行的開發(fā)活動互不干擾并且互相協(xié)作。下圖是軟件發(fā)行和版本管理的總圖：

     

    在上圖中，ADCTR分別代表分析、設(shè)計、編碼實現(xiàn)、測試和發(fā)行。紅線表示主要版本，所有新增功能和重大改進功能都在這個分支上進行，它代表軟件內(nèi)容的增 加。幾個與Time軸平行的線表示補丁版本，對于重要缺陷的修正是在這個分支上進行，它也表示了補丁版本不增加新的內(nèi)容（功能）。同時，主要版本上開發(fā)的 內(nèi)容很多，涉及的文件修改也是數(shù)量巨大的。而補丁版本也稱為Minor版本，這個分支上沒有大量的修改，涉及的文件也很少。另外，我們也可以看到，每次的 發(fā)行都需要一定的時間，而在主要版本發(fā)行期間，主要版本分支理論上是沒有新的開發(fā)內(nèi)容的，這種情況一直維持到新的版本計劃確定為止（實際上，新版本計劃通 常在版本發(fā)行之前就開始制定了）。

    在補丁分支上修改的文件，必須在測試通過后合并到其上面最近的分支中。這樣就保證了次要分支上的修 改不丟失，這些修改同樣也反映在后續(xù)的發(fā)行中。向最近的分支合并的文件，最終會被逐級合并到主要版本中。曾經(jīng)有某國際大型知名軟件開發(fā)商，其安裝程序的一 個小缺陷在一個次要版本中更正了，但后來其發(fā)行的一個主要版本中并沒有修正這個缺陷。出現(xiàn)這種情況一般是因為沒有合并或沒有逐級合并。目前基本上所有的版本管理軟件都支持版本的分支和合并操作。

    也存在多分支（多于兩個）開發(fā)的情況，不過這種情況并不常見，因為控制上的難度很大，也容易出錯。實際上，當主要版本發(fā)行間隔過于密集時，也容易出現(xiàn)控制上的漏洞。

    在實際操作中，通常有兩個問題比較典型，也應(yīng)該引起大家的注意。

    1. 版本主次不分

    在主要版本分支上開發(fā)的內(nèi)容不是遠遠多于補丁版本分支上修改的內(nèi)容，甚至在補丁分支上開發(fā)新增功能。這個問題的嚴重性超出想象。這直接導(dǎo)致版本的合并操作艱難，甚至完全不可能。注意：補丁版本上永遠只能做緊急、小量修改，稍大的缺陷修改都不應(yīng)該在其上進行。

    2. 文件合并問題

    修改后測試通過的文件合并不及時、合并不正確也是常見的一個問題。合并不及時，就象不進行日構(gòu)建一樣，具有同樣的危害。合并不正確會導(dǎo)致后續(xù)的發(fā)行版本包 含已確認解決的問題。這是應(yīng)該在管理上加強控制的。另外，也不要太過于依賴自動的文件合并。