軟件發(fā)布管理流程規(guī)范

1、軟件發(fā)布管理流程規(guī)范編 制：審 核：日 期：版 本：編 號：密 級：修改歷史修改時間修改人修改原因版本精選1. 目標(biāo)2. 發(fā)布流程2.1. 補丁發(fā)布流程.2.2. 主版本發(fā)布流程2.3. 產(chǎn)品實施流程.2.4. VSSI理流程.3. 相關(guān)資料.4.5.7.1.0.1.1.121. 目標(biāo)軟件的發(fā)布過程，需要形成有序的良性循環(huán)。否則，各環(huán)節(jié)流轉(zhuǎn)中容易發(fā)生相互等待、被動接應(yīng)的局面。無形中， 不斷增加了溝通成本，擴大了軟件的風(fēng)險。且對后期造成的影響并不能夠完全預(yù)知、完全估量。因此， 根據(jù)公司內(nèi)部前期已有的習(xí)慣，總結(jié)過去產(chǎn)品的發(fā)布經(jīng)驗，分析統(tǒng)計結(jié)果后，特制定本發(fā)布過程規(guī)范。預(yù)期達到如下目的：1、減少交叉

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

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

4、：包括測試組所有固定資源、臨時調(diào)配資源。5、安裝組（人）：包括負責(zé)公司內(nèi)部、客戶現(xiàn)場的安裝、調(diào)試的人員。6、客戶：所有使用我司產(chǎn)品的用戶。2.1. 補丁發(fā)布流程軟件產(chǎn)品的某個主版本向外發(fā)布給客戶使用后，發(fā)現(xiàn)了錯誤。若這個錯誤給客戶造成了很大的影響，等不及下一主版本，需要立刻修正，我們就需要發(fā)布補?。▽?yīng)VSS上的存放目錄：PatchX.Y）（注：所有補丁要求合并入下一主版本）， 流程圖如下所示。精選未卜丁發(fā)布流程：下圖中每個方框代表一個進程，括號內(nèi)描述該進程的具體內(nèi)容。每個進程均要求相應(yīng)職位填寫補丁簽發(fā)單。精選需求組開發(fā)部配置管理員開始是安（1、安排補丁號、發(fā)布日期, 補丁號中。2、設(shè)置VSS

5、O艮, 關(guān)人，開始執(zhí)行施變更,通常將完成時間相距不遠的安排在同一根據(jù)開發(fā)部經(jīng)理的安排設(shè)置。3、通知相 并公布預(yù)計發(fā)布日期、實施建議）開發(fā)人:執(zhí)行 變更（按照要求 修改代碼、文檔， 完成后，按規(guī)范存放）否 檢查是否通過?提出變更請求（1、事先征得需求澄清會的同意，再填補丁簽發(fā)單。2、通知開發(fā)經(jīng)理）開發(fā)部經(jīng)理:接收任務(wù)（1、安排開發(fā)人、預(yù)計開發(fā)完成時間。2、通知SCM*檢查（1、檢查前兩個環(huán)節(jié)填寫的簽發(fā)單是否符合填寫要求；檢查描述是否清晰、時間要求有無沖突；）測試組測試組長：制定測試計劃（按照簽發(fā)單，安排測試人、預(yù)計測試完成時間）產(chǎn)生alpha版”（開發(fā)部內(nèi)部可產(chǎn)生多個alpha版）安裝alpha

6、測試環(huán)境部門內(nèi)部測試（1、alpha階段的測試，相當(dāng)于單元 測試。2、通知SCM否V測試是否通過？1是產(chǎn)生Beta版（1、檢查相關(guān)文檔是否已備齊；2、根據(jù)簽發(fā)單，檢查當(dāng)前補丁號中提出的變更是否都已執(zhí)行；3、檢查開發(fā)人在CheckIn/out的過程中，是否符合VSST理規(guī)范、版本管理規(guī)范；4、根據(jù)簽發(fā)單，制作補丁發(fā)行說明5、關(guān)閉VSSO6、編譯構(gòu)建beta版；7、通知測試組、安裝組，向其提交該補丁的書面簽發(fā)單）安裝Beta測試環(huán)境（1、編寫/更新補丁安裝手冊；2、選擇測試環(huán)境，安裝補丁 beta版；3、通知測試組、相關(guān)人，同時刷新“公司內(nèi)部產(chǎn)品試用環(huán)境一覽表”白板）驗收測試（1、beta階段的測

7、試,相當(dāng)于集成測試2、通知相關(guān)人測試結(jié)果,含郵件、簽發(fā)單電子格式的回復(fù)。若測試通過，則還包括在書面簽發(fā)單上簽名。）否測試是否通過？1是結(jié)束（轉(zhuǎn)入產(chǎn)品實施流程）產(chǎn)生Release版（1、檢查測試結(jié)果是否已全部通過；2、檢查提交文檔是否已齊全；3、標(biāo)識、備份、記錄。4、通知相關(guān)人。等等詳見：版本發(fā)布前的checkList；）分發(fā)Release版（1、根據(jù)安裝組的工作計劃、根據(jù)各客戶現(xiàn)行情況，組合出不同的安裝包；2、分發(fā)給當(dāng)次執(zhí)行安裝任務(wù)的人。3、通知安裝組。2.2. 主版本發(fā)布流程主版本的發(fā)布流程，與補丁的發(fā)布流程相比，參與的職能部門個數(shù)、次數(shù)明顯增多，且設(shè)置的檢查點也隨之增多。重要的一點，引入客

8、戶監(jiān)督。改變目前的“直到整個版本完全下流水線后，才提交客戶試用”的方法。采取“我們主動爭取客戶全程參與”的方法，每完成一個變更，不一定要待版本中的所有變更完成，立刻放上客戶使用的測試環(huán)境，請客戶在線試用并提意見。（此舉依賴公司實現(xiàn)遠程測試環(huán)境）。 目的： 讓客戶不僅知道我們在干什么，還知道我們干成什么樣，是否滿意。盡量讓客戶的意見在開發(fā)早期提出，越早提出，變更成本越小，且能直接減少后續(xù)的補丁發(fā)布頻率。流程圖如下：精選主版本發(fā)布流程圖（下圖中每個方框代表一個進程，括號內(nèi)描述該進程的具體內(nèi)容。每個進程均要求有物理產(chǎn)出。）精選需求人開發(fā)人提山變、士 1-（1、填寫自己負責(zé)的«產(chǎn)品名版本號開

9、發(fā)計劃清單/測試清單/變更清單（以下簡稱清單）；2、請求召開需求澄清會參與澄清會 （對清單釋疑）評審?fù)ㄟ^？配置管理員測試人/安裝人客戶參與澄清會（對清單提出質(zhì)疑，預(yù)估開發(fā)所需工時）參與清清會（對變更請求提出質(zhì)穎, 預(yù)估測試所需工時）段階求需宣布變更計劃（由需求總負責(zé)人/PM 宣布：1、通知SC檢入 變更計劃；2、通知開 發(fā)部經(jīng)理接收任務(wù)； 3、通知客戶）（完成 時限：上一主版本正式對外發(fā)行前。）（1、檢查有無通過澄清會；2、將一個產(chǎn)品中，各需求人提出的清單中，已通過澄清會的內(nèi)容，合并成一份。從此本流程僅使用合并后的清單。3、存入VSS勺固定目錄、標(biāo) Label;5、通知開發(fā)部經(jīng)理、測試組長重新

10、進入開發(fā)階段提供發(fā)行說明內(nèi)容（各需求人提供自己所轄范圍內(nèi)的說明內(nèi)容，參照樣本填寫）開發(fā)部經(jīng)理：接收任務(wù)（1、安排開發(fā)人、預(yù)計開發(fā)完成時間。2、通知相關(guān)人）段階發(fā)開開發(fā)人：執(zhí)行變更（1、開發(fā)人執(zhí)行變更；2、定期向項目管理組匯報開發(fā)為開發(fā)部門設(shè)置權(quán) 限收集、審核發(fā)行說 明內(nèi)容測試組長：制定測試計劃（按照清單，制定測試大綱、測試計劃）需求確認測試（確認功能是否滿足需求）制作發(fā)行說明網(wǎng)頁 （根據(jù)收集并審核通過 的內(nèi)容，制作成適合客 戶在線閱讀的網(wǎng)頁等格式，變更清單除外）主版本發(fā)布流程圖（續(xù)）需求人開發(fā)人測試人/安裝人客戶配置管理員是是結(jié)束（轉(zhuǎn)入廣品實施流程）客戶是否否參與測試？R物理配置審核（1、各類

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