軟體發布管理流程規範

編制：審核：

日期：版本：

編號：密級：

修改歷史

目錄1. 目標 4

2. 發布流程 4

2.1. 補丁發布流程 4

2.2. 主版本發布流程 6

2.3. 產品實施流程 9

2.4. vss管理流程 10

3. 相關資料 11

軟體的發布過程，需要形成有序的良性迴圈。否則，各環節流轉中容易發生相互等待、被動接應的局面。無形中，不斷增加了溝通成本，擴大了軟體的風險。

且對後期造成的影響並不能夠完全預知、完全估量。

因此，根據公司內部前期已有的習慣，總結過去產品的發布經驗，分析統計結果後，特制定本發布過程規範。預期達到如下目的：

1、減少交叉溝通。通過將發布過程流程化，使每乙個環節的執行者都非常清楚自己的產入產出，受誰的影響，將影響誰。當遇到困難時，能明確的定位尋找到關鍵人物溝通解決。

避免當需要獲取一件事情的進展情況時，需要廣泛徵詢才能掌握的現象。減少交叉溝通成本。

2、提高工作預見性。流程一旦啟動，流程中的所有人員便被觸動。各環節執行人能迅速在早期預算出自己的「參與時間」、「參與內容」、「參與工作量」，主動提前做出安排、準備，避開人力、時間等資源上的衝突。

且一旦發現衝突，便能立刻「報警」，報得越早，越能提前應對，減少損失。

3、提高可控性。軟體發布就像道路交通。交通電台有了可靠的訊息渠道（取決於上述「1、減少交叉溝通」），便能隨時掌握路面交通狀況，配合可預見的行車計畫（取決於上述「2、提高工作預見性」），當然更能向車隊提供有價值的訊息。

因此，車隊領導能做出更有控制力的指令，各車隊協調行駛，整個交通自然更受控。

一條早已設計好的行車路線，加上提前準備就緒的車隊人馬，再加上行進途中密切配合的交通電台。與沒有固定線路，需要時才去調配車馬，電台資訊又不暢的隊伍相比，哪乙個更能成功到達目的地？

本章節的流程圖中，將使用下列簡稱。

1、需求組(人)：包括需求總負責人(或pm)、各模組需求負責人。

2、開發部(人)：包括技術開發部全體成員。

3、配置管理員：或簡稱scm，包括技術研發部的配置管理組成員。

4、測試組(人)：包括測試組所有固定資源、臨時調配資源。

5、安裝組(人)：包括負責公司內部、客戶現場的安裝、除錯的人員。

6、客戶：所有使用我司產品的使用者。

軟體產品的某個主版本向外發布給客戶使用後，發現了錯誤。若這個錯誤給客戶造成了很大的影響，等不及下一主版本，需要立刻修正，我們就需要發布補丁（對應vss上的存放目錄：patch[x.

y]）（注：所有補丁要求合併入下一主版本）。流程圖如下所示。

主版本的發布流程，與補丁的發布流程相比，參與的職能部門個數、次數明顯增多，且設定的檢查點也隨之增多。

重要的一點，引入客戶監督。改變目前的「直到整個版本完全下流水線後，才提交客戶試用」的方法。採取「我們主動爭取客戶全程參與」的方法，每完成乙個變更，不一定要待版本中的所有變更完成，立刻放上客戶使用的測試環境，請客戶**試用並提意見。

（此舉依賴公司實現遠端測試環境）。目的：讓客戶不僅知道我們在幹什麼，還知道我們乾成什麼樣，是否滿意。

盡量讓客戶的意見在開發早期提出，越早提出，變更成本越小，且能直接減少後續的補丁發布頻率。

流程圖如下：

為方便大家更加理解軟體的整個發布迴圈過程，在此簡單介紹軟體通過release階段後的實施流程，它包括安裝、培訓等內容。具體的規範制度，以實施部門制定的為準。

簡單介紹vss的使用流程如下，具體詳細的規則另述。

3.1 軟體版本號的命名約定、分支約定