發(fā)布管理流程規(guī)范標準

1、產(chǎn)品發(fā)布管理流程規(guī)范編 制：審 核：日 期：版 本：編 號： 密 級：1 .目標 32 .發(fā)布流程 42.1. 補丁發(fā)布流程 42.2. 主版本發(fā)布流程 62.3. 產(chǎn)品實施流程 92.4. VSS管理流程 103 .相關資料 111.目標軟件產(chǎn)品的發(fā)布過程，需要形成有序的良性循環(huán)。否則，各環(huán)節(jié)流轉(zhuǎn)中容易 發(fā)生相互等待、被動接應的局面。無形中，不斷增加了溝通成本，擴大了軟件的 風險。且對后期造成的影響并不能夠完全預知、完全估量。因此，根據(jù)公司內(nèi)部前期已有的習慣，總結(jié)過去產(chǎn)品的發(fā)布經(jīng)驗，分析統(tǒng)計 結(jié)果后，特制定本發(fā)布過程規(guī)范。預期達到如下目的：1、減少交叉溝通。通過將發(fā)布過程流程化，使每一個環(huán)節(jié)

2、的執(zhí)行者都非常 清楚自己的產(chǎn)入產(chǎn)出，受誰的影響，將影響誰。當遇到困難時，能明確的定位尋 找到關鍵人物溝通解決。避免當需要獲取一件事情的進展情況時，需要廣泛征詢 才能掌握的現(xiàn)象。減少交叉溝通成本。2、提高工作預見性。流程一旦啟動，流程中的所有人員便被觸動。各環(huán)節(jié) 執(zhí)行人能迅速在早期預算出自己的“參與時間”、“參與內(nèi)容”、“參與工作量”， 主動提前做出安排、準備，避開人力、時間等資源上的沖突。且一旦發(fā)現(xiàn)沖突， 便能立刻“報警”，報得越早，越能提前應對，減少損失。3、提高可控性。產(chǎn)品發(fā)布就像道路交通。交通電臺有了可靠的消息渠道（取 決于上述“1、減少交叉溝通”），便能隨時掌握路面交通狀況，配合可預見

3、的行車計 劃（取決于上述“ 2、提高工作預見性”），當然更能向車隊提供有價值的消息。 因止匕, 車隊領導能做出更有控制力的指令，各車隊協(xié)調(diào)行駛，整個交通自然更受控。一條早已設計好的行車路線，加上提前準備就緒的車隊人馬，再加上行進途 中密切配合的交通電臺。與沒有固定線路，需要時才去調(diào)配車馬，電臺信息又不 暢的隊伍相比，哪一個更能成功到達目的地?本章節(jié)的流程圖中，將使用下列簡稱。1、需求組（人）：包括需求總負責人（或PM）、各模塊需求負責人。2、開發(fā)部（人）：包括技術開發(fā)部全體成員。3、配置管理員：或簡稱SCM ,包括技術研發(fā)部的配置管理組成員。4、測試組（人）：包括測試組所有固定資源、臨時調(diào)配資

4、源。5、安裝組（人）：包括負責公司內(nèi)部、客戶現(xiàn)場的安裝、調(diào)試的人員。6、客戶：所有使用我司產(chǎn)品的用戶。2.1. 補丁發(fā)布流程軟件產(chǎn)品的某個主版本向外發(fā)布給客戶使用后，發(fā)現(xiàn)了錯誤。若這個錯誤給客戶造成了很大的影響，等不及下一主版本，需要立刻修正，我們就需要發(fā)布補丁（對應VSS上的存放目錄：PatchX.Y）（注：所有補丁要求合并入下一主版 本）。流程圖如下所示。未卜丁發(fā)布流程：下圖中每個方框代表一個進程，括號內(nèi)描述該進程的具體內(nèi)容。每個進程均要求相應職位填寫補丁簽發(fā)單需求組開發(fā)部配置管理員測試組（1、事先征得需 求澄清會的同意， 再填補丁簽發(fā)單。2、通知開發(fā)經(jīng)理）開發(fā)部經(jīng)理：接收任務（1、安排開

5、發(fā)人、預計開發(fā)完成時間。2、通知scm檢查（1、檢查前兩個環(huán)節(jié)填寫的簽發(fā)單是否符合填寫要求；檢查描述是否清晰、時間要求有無沖突；）測試組- 定測記 （按照簽 排測試人、 試完成長：制 1計劃 殳單，安 預計測 時間）安裝Beta測試劃、境（1、編寫/更新補丁安裝手冊；2、選擇測試環(huán)境，安裝補丁 beta版；3、通知測試組、相關人，同時刷新“公司內(nèi)部產(chǎn)品試用環(huán)境一覽表”白板）驗收測試（1、beta階段的測試,相當于集成測試2、通知相關人測試結(jié)果,含郵件、簽發(fā)單電子格式的回復。若測試通過，則還包括在書面簽發(fā)單上簽名。）否 一 ，測試是否通過？.iT是否.檢查是否通過?安排補丁號（1、安排補丁號、發(fā)

6、布日期，通常將完成時間相距不遠的安排在同一 補丁號中。2、設置VS的限，根據(jù)開發(fā)部經(jīng)理的安排設置。3、通知相關人，開始執(zhí)行施變更，并公布預計發(fā)布日期、實施建議）開發(fā)人：執(zhí)行 變更（按照要求 修改代碼、文檔， 完成后，按規(guī)范存 放）廣生al（開發(fā)部內(nèi)部可產(chǎn) 生多個alpha版） 安裝 alpha環(huán)境部門內(nèi)也測試（1、alpha階段的 測試，相當于單元 測試。2、通知scm測試是否通過？是產(chǎn)生Beta版（1、檢查相關文檔是否已備齊；2、根據(jù)簽發(fā)單，檢查當前補丁號中提出的變更是否都已執(zhí)行；3、檢查開發(fā)人在CheckIn/out的過程中，是否符合VSST理規(guī)范、版本管理規(guī)范；4、根據(jù)簽發(fā)單，制作補丁發(fā)

7、行說明5、關閉VSSO6、編譯構(gòu)建beta版；7、通知測試組、安裝組，向其提交該補丁的書面簽發(fā)單）產(chǎn)生Release版（1、檢查測試結(jié)果是否已全部通過；2、檢查提交文檔是否已齊全；3、標識、備份、記錄。4、通知相關人。等等詳見：版本發(fā)布前的checkList；）分發(fā)Release版（1、根據(jù)安裝組的工作計劃、根據(jù)各客戶現(xiàn)行情況，組合出不同的安裝包；2、分發(fā)給當次執(zhí)行安裝任務的人。3、通知安裝組。結(jié)束（轉(zhuǎn)入產(chǎn)品實施流程）2.2. 主版本發(fā)布流程主版本的發(fā)布流程，與補丁的發(fā)布流程相比，參與的職能部門個數(shù)、次數(shù)明 顯增多，且設置的檢查點也隨之增多。重要的一點，引入客戶監(jiān)督。改變目前的“直到整個版本完

8、全下流水線后，才提交客戶試用”的方法。采取“我們主動爭取客戶全程參與”的方法，每完成 一個變更，不一定要待版本中的所有變更完成，立刻放上客戶使用的測試環(huán)境， 請客戶在線試用并提意見。（此舉依賴公司實現(xiàn)遠程測試環(huán)境）。目的：讓客戶不 僅知道我們在干什么，還知道我們干成什么樣，是否滿意。盡量讓客戶的意見在 開發(fā)早期提出，越早提出，變更成本越小，且能直接減少后續(xù)的補丁發(fā)布頻率。流程圖如下：需求人開發(fā)人配置管理員測試人/安裝人客戶段階求需段階發(fā)開提出變蚩請求（1、填寫自己負責的«產(chǎn)品名版本號開發(fā)計劃清單/測試清單/變更清單（以下簡稱清單）；2、請求召開需求澄清會參與澄清會（對清單釋疑）4、.

9、1,人_參與澄清會（對清單提出質(zhì)疑，預估開發(fā)所需工時）（對變更請求提出質(zhì)穎,預估測試所需工時）宣布變更計劃（由需求總負責人/PM 宣布：1、通知SC檢入 變更計劃；2、通知開 發(fā)部經(jīng)理接收任務； 3、通知客戶）（完成 時限：上一主版本正式 對外發(fā)行前。）（各需求人提供自己所轄范圍內(nèi)的說明內(nèi)容，參照樣本填寫）開發(fā)部經(jīng)理：接收任務（1、安排開發(fā)人、預計開發(fā)完成時間。2、通知相關人）開發(fā)人：執(zhí)行變更（1、開發(fā)人執(zhí)行變更；2、定期向項目管理組匯報開發(fā)產(chǎn)生alpha版（可產(chǎn)生若干個alpha版，直 至所有變更完成）安裝alpha測試環(huán)境需求確認測試（確認功能是否滿足需求）部門內(nèi)部測試（alpha階段的測

10、試，相當于單元測試，確認功能是否完整、是否正常運行、相關手冊是否最新）（1、檢查有無通過澄清會；2、將一個產(chǎn)品中，各需求人提出的清單中，已通過澄清會的內(nèi)容，合并成一份。從此本流程僅使用合并后的清單。3、存入VSS勺固定目錄、標 Label;5、通知開發(fā)部經(jīng)理、測試組長為開發(fā)部門設置權 限11收集、審核發(fā)行說 明內(nèi)容試計劃（按照清單，制定測試大綱、測試計劃）重新進入開發(fā)階段, 否是否參與？-是段測試通過？二 版本測試（1、根據(jù)測試計劃測 試；2、寫安裝手冊）制作發(fā)行說明網(wǎng)頁 （根據(jù)收集并審核通過 的內(nèi)容，制作成適合客 戶在線閱讀的網(wǎng)頁等格式，變更清單除外）需求確認測試 （確認功能是否滿 足要求，

11、盡可能提 出改進意見）需求人開發(fā)人 配置管理員測試人/安裝人客戶（1、各類文檔有無備齊；2、有 無全部測試通過一等等，詳見Checklist » )廣生Beta?。?、關閉vsSOM； 2、標Label;3、編譯構(gòu)建beta版、備份、通知相關人；3、制作變更清單網(wǎng)頁等等，詳見執(zhí)行列表）安裝Beta測試環(huán)境（公司內(nèi)部用）（1、根據(jù)測試計劃、安裝手冊，安裝測試環(huán)境（可能有多套環(huán)境），驗證安裝過程是否正確；2、通知SCM測試組、刷新“公司內(nèi)部產(chǎn)品試用環(huán)境一覽表”）客戶是否否參與測試？是安裝Be*測試環(huán)境（客戶用）（1、根據(jù)客戶需要，選擇安裝環(huán)境，并進行安裝；2、通知SCIM各需求負責人）驗收測試（1、根據(jù)測試計劃測 試；2、回復測試結(jié)果（含郵件、上傳VSS 書面三種方式）安裝記錄驗收測試（1、對產(chǎn)品進行 測試、試用，包 括性能、功能方 面的測試，盡可能提出意見）測試通過?否，重新迪入開發(fā)階段物理配置審核（1、各類文檔有無備齊；2、有 無全部測試通過；3、檢查變更清 單網(wǎng)頁。4、下一主版本計劃已備 妥等等，詳見« Checklist » ）產(chǎn)生Release版（1、標識、備份、記錄。2、通知相關人。等等詳見：版本發(fā)布前的checklist » ；）分發(fā)Release版（1、根據(jù)安裝組的工作計劃、根據(jù)各客戶現(xiàn)