技術(shù)部軟件版本管理規(guī)范

1、技術(shù)部軟件版本規(guī)范文檔建立 / 修改記錄 ：序號版本號建立 /修改編寫人、時(shí)間審核人、時(shí)間審批人、時(shí)間1V1.0建立李洋洋、 2016年李洋洋、 2016年01月2901月29版本管理規(guī)范【新建項(xiàng)目版本管理部分】1，項(xiàng)目組接到項(xiàng)目需求，1.1，開發(fā)組出項(xiàng)目設(shè)計(jì)和開發(fā)計(jì)劃；1.2，測試在 Git 中建立空項(xiàng)目 (項(xiàng)目名稱開會(huì)時(shí)候會(huì)有， 沒有需要問 )，形成 master 版本，版本設(shè)定為。2，組長發(fā)郵件給技術(shù)總監(jiān)，并且抄送給項(xiàng)目經(jīng)理和測試。郵件內(nèi)容：開發(fā)計(jì)劃文檔url 和開發(fā)版本號，請批準(zhǔn)第一階段(開發(fā)計(jì)劃中會(huì)包含)開發(fā)。3，得到批準(zhǔn)開發(fā)回復(fù)后，測試從 建立分支版本，打開版本參與人員的更新權(quán)限，

2、并且將url 給組長。4，組長 download 項(xiàng)目， 上傳項(xiàng)目可運(yùn)行框架，并且更新GIT 中的 readme 文檔并通知開發(fā)；5，開發(fā)者必須按時(shí)按功能點(diǎn)來提交(提交時(shí)需寫相應(yīng)描述)項(xiàng)目到 GIT 中，并且push 前必須測試，保證代碼不能有運(yùn)行異常，導(dǎo)致無法測試5.1， Push 結(jié)束后，開發(fā)者繼續(xù)開發(fā)下一個(gè)功能點(diǎn)。5.2， push 結(jié)束會(huì)自動(dòng)化構(gòu)建，自動(dòng)化構(gòu)建完成后系統(tǒng)會(huì)自動(dòng)通知測試人員進(jìn)行測試，測試人員需先關(guān)閉版本參與人員的更新權(quán)限，再按功能點(diǎn)來測試bug，然后更新bug 文檔和測試用例文檔的內(nèi)容(有無 bug 都需要更新 )，隨即打開更新權(quán)限并通知組長。6，開發(fā)者下一個(gè)功能點(diǎn)提交時(shí)

3、，同上要求。7，第一階段最后一個(gè)功能點(diǎn)提交完畢后，測試者關(guān)閉此版本參與者更新權(quán)限，然后將此版本建分支版本并且給出版本url 給組長，繼續(xù)進(jìn)行測試最后一個(gè)功能點(diǎn)bug。8，組長通知組員進(jìn)行bug（ bug 一般會(huì)比較少，bug 很多只能說明開發(fā)者開發(fā)質(zhì)量有問題）修改，給出修改版本地址。9，修改完畢后提交，測試人員再次關(guān)權(quán)限且測試，如仍然有相關(guān)修改支版本(這里是中再次建立修改版本(此時(shí)是bug 存在，更新相應(yīng)文檔并在，隨即給出版本url 給組長。 ps：提交版本如有沖突找組長調(diào)節(jié)。10，第一階段開發(fā)完全完成后開始開發(fā)第二階段任務(wù)，重復(fù) 29 步驟，相應(yīng)的版本號會(huì)變?yōu)閺拈_始，同里修改版本號則是11，

4、當(dāng)全部階段任務(wù)完成(指的是開發(fā)完成并測試無bug)，測試將最新的修改完成的版本(應(yīng)該是，x 為任意數(shù)字 )合并到 master 版本中，此時(shí)版本號設(shè)定為。測試發(fā)郵件給技術(shù)總監(jiān)，抄送給項(xiàng)目經(jīng)理、開發(fā)組長和運(yùn)維人員，請批準(zhǔn)線上發(fā)布，得到肯定回復(fù)后，運(yùn)維開始執(zhí)行發(fā)布。郵件內(nèi)容：項(xiàng)目軟件上線文檔url（存在石墨系統(tǒng)中），請批準(zhǔn)線上發(fā)布。【master 版本修改版本管理部分】12，承接上文，發(fā)布到線上的軟件不排除有時(shí)會(huì)出現(xiàn)bug，此時(shí)如必須要解決這些bug，則重復(fù)上文的步驟 1步驟 11，不同的地方在以下幾點(diǎn)：12.1，和上文 1.2 不同，測試人員任務(wù)不是在此處新建空項(xiàng)目，而是將master 版本開分

5、支(V1.0.1),然后給出 url 給組長；12.2，此次修改的所有版本號則變?yōu)閂1.0.x 形式；12.3，修改完成后（指的是bug 俱已修復(fù)完成），測試再次封測，將分支權(quán)限關(guān)閉并且整合到 V1.0.0 版本的 master 中，繼續(xù)按步驟上線等操作。修復(fù)完成。12.4，上線之后，又發(fā)現(xiàn)了bug，仍然需要修復(fù)，則再次重復(fù)12.112.3 步驟，不過版本號變?yōu)閂1.0.2/V1.0.3 形式?！卷?xiàng)目整改版本管理部分】13，日后，此項(xiàng)目需要整改 (比如：增減模塊、改變功能等)時(shí)，基本按照上面的112 步驟執(zhí)行，不同的地方在以下幾點(diǎn)：13.1，和上文 1.2 不同，測試人員任務(wù)不是在此處新建空項(xiàng)

6、目，而是將master 版本開分支，指定版本號為 V2.0.0(master 版本整改超過50%)或者 V1.1.0(master版本整改小功能等 ),然后給出 url 給組長；13.2，此次再開發(fā)任務(wù)的所有版本號則變?yōu)閂2.x.x 或者 V1.1.x 形式；13.3，開發(fā)完成后（指的是再開發(fā)完成并測試無bug），測試封測，將分支權(quán)限關(guān)閉并且整合到現(xiàn)有的master 版本中，繼續(xù)按步驟上線等操作。再開發(fā)完成。版本管理規(guī)范流程圖版本管理規(guī)范流程圖2016 年1 月29 日項(xiàng)目新建流程2016/1/29組長接到項(xiàng)目開發(fā)組：1，項(xiàng)目設(shè)計(jì)2，開發(fā)計(jì)劃開發(fā)計(jì)劃完成后組長：測試者：建立空項(xiàng)目，形成mast

7、er版本等待郵件通知發(fā)郵件，獲批第一階段開發(fā)組長：1， download項(xiàng)目，上傳項(xiàng)目框架，更新 GIT 中 readme文檔2 ，通知開發(fā)者開發(fā)開發(fā)者：1，按時(shí)按功能點(diǎn)提交代碼到 GIT 中，需保證可測試2，繼續(xù)開發(fā)下一個(gè)功能點(diǎn)測試者：測試時(shí)關(guān)閉 GIT 中版本參與開發(fā)人員更新權(quán)限，測試完成打開權(quán)限并更新相關(guān)文檔和通知組長組長：1，通知開發(fā)者修復(fù) bug并給出修改版本 url測試者：發(fā)郵件給技術(shù)總監(jiān)，抄送給項(xiàng)目經(jīng)理、開發(fā)組長和運(yùn)維人員，請批準(zhǔn)線上發(fā)布，得到肯定回復(fù)后，運(yùn)維開始執(zhí)行發(fā)布。等待郵件通知階段任務(wù)完成Bug再修復(fù)Bug全部修改完畢獲得批準(zhǔn)測試者：1，從 master建分支版本2，打開分支參與開發(fā)人員的更新權(quán)限3，將分支 url 給組長測試者：1，關(guān)閉當(dāng)前版本更新權(quán)限，從版本建立分支并將此版本 url給組長2，繼續(xù)測試本階段最后一個(gè)功能點(diǎn)測試者：1，關(guān)閉更新權(quán)限并測試，更新相關(guān)文檔2，如仍有 Bug(Bug再修復(fù)流程 )，則繼續(xù)在上一個(gè)版本上建立分支版本并將此版本 url 給組長3，如無 Bug測出