發行是產品開發完成并交付客戶安裝、配置、使用的過程。軟件發行做為生產完成或階段性完成時刻的活動，不僅是一個短時期的任務，它和開發過程中的其他活動密切相關。
在整個軟件的生命周期中，開發活動總是迭代進行的。即使對于傳統的軟件開發方法（結構化設計），在維護階段一個用戶的需求變更，將導致軟件的新版本發行，這時候不得不進行被動的迭代——在原軟件的基礎上改進并發行改進的補丁或者完整版本。但人們在面向對象的開發方法中，更加傾向于主動的迭代過程，以提高軟件產品的質量。
我們也用更現代的視角來觀察整個過程和軟件發行這個活動。開發計劃在最初時刻定義了發行版本的內容，正常情況下，未來的發行將包含計劃中的所有開發內容。開發過程中的各種活動如評審、測試等保證了發行的質量。版本管理是一個好的發行成功的根本保證。發行活動記錄軟件版本和發行的目標客戶，以進行后期的維護如補丁發行、版本更新。
軟件的發行是有節奏、有內容、有質量的。節奏保證了開發人員和最終客戶的一致，所有人都知道版本將在何時發行。內容滿足最終客戶的期望。質量保證產品即滿足用戶的需求，又能夠提高后續版本發行能力。
軟件發行中主要存在的問題有三種：短路的發行、內容膨脹和缺陷積累。
短路的發行
短路的發行是指為了保證發行的節奏，或者因為設定了DEADLINE而導致在開發過程中縮減活動，如不經評審、粗略測試等。這導致了發行質量的下降，并影響到后續的發行版本。這在國內的軟件企業中非常嚴重，我們常�？吹竭B續的加班和最終的低質量的產品并存。
解決這個問題的方法是使用嚴密可行的、可變更的版本計劃。嚴密可行的計劃可以直接保證版本及時發行；當發現不能及時發行版本時縮減版本計劃中的內容可以在保證及時發行的基礎上同時保證版本的質量，畢竟質量才是最重要的。
內容的膨脹
內容的膨脹是指在版本開發過程中，不斷的增加計劃外的內容。這必然導致兩個結果之一：要么降低版本質量，要么拖延版本發行時間。任何一項都不是我們想看到的。這和項目經理/需求人員的控制能力有關，很多時候，頂住客戶的壓力不是一件容易的事情。
所以這個問題的最終解決方案是提高項目經理/需求人員的能力，提高客戶對軟件開發的理解。除此之外，我們能夠做的就是在增加內容的同時縮減低優先等級的內容，來保證發行的質量和節奏。
缺陷的積累
這個問題大家都已經注意到了，在發行前期，匆忙的構建過程中發現大量的缺陷，最終導致發行的拖延。
解決這個問題的手段也比較簡單，就是進行有效的日構建，盡早發現并解決缺陷，爭取在發行時刻的主動權。
我們來看一個例子：
我本來想在今晚12：00以前寫完整個發行管理的，但現在看來我是不能完成了。我不想拖到12：00以后再發這篇文章，也不能敷衍的隨便寫寫了事。所以我砍掉后面的發行管理的細節內容，這些內容將在后續版本中發行。這樣我即保證了本篇的質量，也趕上了我給自己定義的時間線。
以上講了發行管理的一些基本理論，最主要最根本的一點就是不要對發行的內容失去控制。在這個基礎上逐步加強對發行節奏的協調，可以形成良好的軟件發行管理制度，提高軟件發行能力。下面要說的是發行中的一些細節。
在一個軟件的生命周期中，一般會有多次發行，尤其對于迭代開發的軟件更是這樣。每隔一段時間，生產商就會發行一個主要版本，其中包含大量功能改進或新增功能。同時，在每個主要版本發行的間隔中，也會發行一些對當前用戶使用版本的補丁。這種情況是由軟件本身的性質決定的。對于實體的產品（如汽車），當發現設計缺陷時必須要“召回”；而對于非實體的、形式的軟件產品，當發現缺陷時，就需要發行一個更正的補丁。實際上，軟件的主要版本和補丁版本往往是同時開發/ 修改的。版本管理和發行管理使用這種并行的開發活動互不干擾并且互相協作。下圖是軟件發行和版本管理的總圖：
在上圖中，ADCTR分別代表分析、設計、編碼實現、測試和發行。紅線表示主要版本，所有新增功能和重大改進功能都在這個分支上進行，它代表軟件內容的增加。幾個與Time軸平行的線表示補丁版本，對于重要缺陷的修正是在這個分支上進行，它也表示了補丁版本不增加新的內容（功能）。同時，主要版本上開發的內容很多，涉及的文件修改也是數量巨大的。而補丁版本也稱為Minor版本，這個分支上沒有大量的修改，涉及的文件也很少。另外，我們也可以看到，每次的發行都需要一定的時間，而在主要版本發行期間，主要版本分支理論上是沒有新的開發內容的，這種情況一直維持到新的版本計劃確定為止（實際上，新版本計劃通常在版本發行之前就開始制定了）。
在補丁分支上修改的文件，必須在測試通過后合并到其上面最近的分支中。這樣就保證了次要分支上的修改不丟失，這些修改同樣也反映在后續的發行中。向最近的分支合并的文件，最終會被逐級合并到主要版本中。曾經有某國際大型知名軟件開發商，其安裝程序的一個小缺陷在一個次要版本中更正了，但后來其發行的一個主要版本中并沒有修正這個缺陷。出現這種情況一般是因為沒有合并或沒有逐級合并。目前基本上所有的版本管理軟件都支持版本的分支和合并操作。
也存在多分支（多于兩個）開發的情況，不過這種情況并不常見，因為控制上的難度很大，也容易出錯。實際上，當主要版本發行間隔過于密集時，也容易出現控制上的漏洞。
在實際操作中，通常有兩個問題比較典型，也應該引起大家的注意。
1. 版本主次不分
在主要版本分支上開發的內容不是遠遠多于補丁版本分支上修改的內容，甚至在補丁分支上開發新增功能。這個問題的嚴重性超出想象。這直接導致版本的合并操作艱難，甚至完全不可能。注意：補丁版本上永遠只能做緊急、小量修改，稍大的缺陷修改都不應該在其上進行。
2. 文件合并問題
修改后測試通過的文件合并不及時、合并不正確也是常見的一個問題。合并不及時，就象不進行日構建一樣，具有同樣的危害。合并不正確會導致后續的發行版本包含已確認解決的問題。這是應該在管理上加強控制的。另外，也不要太過于依賴自動的文件合并。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
