軟件版本管理規(guī)范

1、軟件版本管理規(guī)范第一章目的本規(guī)范詳細(xì)規(guī)定軟件項(xiàng)目版本管理的對(duì)象、存儲(chǔ)目錄、分支、權(quán)限、維護(hù)等內(nèi)容，使軟件項(xiàng)目版本管理流程化并規(guī)范化，確保在系統(tǒng)開發(fā)和實(shí)施過程中項(xiàng)目的完整性和一致性。1.第二章適用范圍2.所有系統(tǒng)開發(fā)及實(shí)施項(xiàng)目的軟件項(xiàng)目都應(yīng)進(jìn)行版本管理。項(xiàng)目中所有正式文檔和代碼都應(yīng)納入配置庫（可使用工具建立配置庫，本文所述使用的是svn ）進(jìn)行版本管理。3.第三章職責(zé)4.配置庫管理員：負(fù)責(zé)配置庫的日常維護(hù)和管理；監(jiān)督開發(fā)及測試部門及時(shí)提交版本管理對(duì)象（即配置項(xiàng)）。5.此崗位可由開發(fā)或測試人員兼任。6.第四章內(nèi)容7. 版本管理對(duì)象8.包括但不限于：9.項(xiàng)目總體計(jì)劃10.可行性研究報(bào)告11.開發(fā)計(jì)劃

2、12.需求說明書13.需求設(shè)計(jì)原型14.設(shè)計(jì)說明書15.系統(tǒng)開發(fā)變更申請(qǐng)單16.系統(tǒng)管理手冊(cè)17.用戶操作手冊(cè)18.培訓(xùn)計(jì)劃19.培訓(xùn)記錄20.源程序21.支持系統(tǒng)運(yùn)行的配置文件22.存儲(chǔ)過程腳本23.測試計(jì)劃24.測試用例25.測試腳本26.測試報(bào)告27.上線計(jì)劃28.上線申請(qǐng)29.版本維護(hù)日志. 配置庫的目錄結(jié)構(gòu)每個(gè)項(xiàng)目在配置庫中應(yīng)擁有唯一的項(xiàng)目名稱。配置庫目錄結(jié)構(gòu)與項(xiàng)目內(nèi)部的目錄結(jié)構(gòu)建議按下列格式創(chuàng)建。配置庫目錄結(jié)構(gòu)規(guī)劃：tags(發(fā)布) trunk(主版本 ) projecta src my_mooc doc tool 。branches(分支) sy_abc tj_abc wh_mo

3、oc 其中，項(xiàng)目內(nèi)部的目錄結(jié)構(gòu)：| projecta | src （保存該項(xiàng)目的源程序）| doc （保存項(xiàng)目相關(guān)文檔）| 000.項(xiàng)目管理（保存項(xiàng)目過程管理相關(guān)文檔）| 010.項(xiàng)目計(jì)劃（保存項(xiàng)目計(jì)劃相關(guān)文檔）| 020.項(xiàng)目需求（保存項(xiàng)目需求相關(guān)文檔）| 030.系統(tǒng)設(shè)計(jì)（保存項(xiàng)目設(shè)計(jì)相關(guān)文檔）| 030.系統(tǒng)測試（保存項(xiàng)目代碼測試相關(guān)文檔）| 040.系統(tǒng)實(shí)施（保存項(xiàng)目部署實(shí)施相關(guān)文檔）| 050.系統(tǒng)運(yùn)維（保存項(xiàng)目運(yùn)維文檔，包括培訓(xùn)、用戶手冊(cè)等）| 060.技術(shù)資料（保存項(xiàng)目技術(shù)文檔，包括第三方技術(shù)資料等）| 。（保存項(xiàng)目過程管理相關(guān)文檔）| tool （包括該項(xiàng)目特定的開發(fā)、編譯、測

4、試等工具）. 分支(branch) 建議使用分支來協(xié)同不同職能小組對(duì)同一個(gè)配置庫的使用，可按照以下方式進(jìn)行分支的管理。解決方案建立三個(gè)分支，包括主版本開發(fā)(trunk)、分支版本開發(fā) (branches)和發(fā)布(tags)。主版本開發(fā)是所有分支版本的基準(zhǔn)版本，主版本的開發(fā)分支。開發(fā)部門開發(fā)使用。分版本開發(fā)主版本的分支版本，供開發(fā)部門開發(fā)使用。開發(fā)工程師如果以主版本為基準(zhǔn)，進(jìn)行軟件項(xiàng)目開發(fā)，要先將trunk 目錄下的代碼分支到branches目錄的一個(gè)子目錄，在那里對(duì)代碼進(jìn)行開發(fā)。多個(gè)主版本的分版本可通過在branches 頂級(jí)目錄創(chuàng)建多個(gè)分支目錄來區(qū)分。發(fā)布測試和發(fā)布專用分支，該分支代碼不允許

5、任何形式的修改。每個(gè)經(jīng)過測試后的不同版本的代碼做快照放到此分支文件夾下。. 權(quán)限管理應(yīng)對(duì)配置庫的訪問權(quán)限進(jìn)行管理，確保軟件系統(tǒng)的完整性和安全性。建議按如下方式進(jìn)行管理。開發(fā)工程師僅擁有自己所屬項(xiàng)目的add file、delete file、check out、check in權(quán)限，無目錄創(chuàng)建和刪除權(quán)限。開發(fā)工程師若想創(chuàng)建目錄，需向配置庫管理員申請(qǐng)。測試工程師擁有每個(gè)項(xiàng)目的測試分支的add file、delete file、check out、check in權(quán)限，無目錄創(chuàng)建和刪除權(quán)限，對(duì)于其他分支只有只讀權(quán)限。配置庫管理員擁有全部權(quán)限，但增刪項(xiàng)目和增刪目錄需要有項(xiàng)目負(fù)責(zé)人批準(zhǔn)。其他人員若需要配

6、置庫訪問權(quán)限，需經(jīng)技術(shù)總監(jiān)或經(jīng)技術(shù)總監(jiān)授權(quán)的項(xiàng)目經(jīng)理批準(zhǔn)，由配置庫管理員分配權(quán)限。. 版本管理應(yīng)對(duì)軟件系統(tǒng)的版本進(jìn)行管理，確保版本的準(zhǔn)確性和可追溯性。建議按如下方式進(jìn)行管理。版本維護(hù)軟件工程各階段產(chǎn)生的各種文檔和代碼，應(yīng)及時(shí)并統(tǒng)一上載到配置庫由配置庫管理員統(tǒng)一管理。對(duì)于要修改的配置項(xiàng)，應(yīng)從配置庫中檢出（check out）后修改，修改完畢后及時(shí)檢入（ check in），并填寫修改的原因和內(nèi)容。配置項(xiàng)的歷史版本應(yīng)保存在配置庫中。分支遷移從開發(fā)分支到測試分支的遷移，由開發(fā)工程師操作。遷移的時(shí)機(jī)有：1. 當(dāng)開發(fā)負(fù)責(zé)人提交測試申請(qǐng)時(shí)；2. 開發(fā)過程中進(jìn)行測試，修改好一個(gè)或多個(gè)bug，需要測試工程師驗(yàn)

7、證時(shí)。從測試分支到發(fā)布分支的遷移，由配置庫管理員操作。遷移的時(shí)機(jī)有：1.當(dāng)開發(fā)組提交上線申請(qǐng)時(shí)。對(duì)于每個(gè)項(xiàng)目從測試分支到發(fā)布分支的遷移，配置庫管理員要建立分支遷移日志，并詳細(xì)記錄。版本升級(jí)軟件系統(tǒng)遷移到發(fā)布分支后，生成新的版本。每個(gè)系統(tǒng)新的版本不僅以分支形式存在于配置庫中，并且要以獨(dú)立壓縮包形式備份。版本的命名規(guī)則為， version 1. n1是系統(tǒng)編號(hào)。當(dāng)項(xiàng)目整體重新設(shè)計(jì)時(shí)，n1 加 1，基數(shù)為 1 2. n2是模塊編號(hào)。當(dāng)模塊重新設(shè)計(jì)時(shí)，n2 加 1，基數(shù)為 0 3. n3是功能編號(hào)。 當(dāng)項(xiàng)目增加某一功能， 或某一功能需要修改時(shí)， n3 加 1，基數(shù)為 0 4. n4是 bug編號(hào)。當(dāng)項(xiàng)

8、目的 bug被修復(fù)時(shí)， n4 加 1，基數(shù)為 0 5. t/r5中的 t/r分別對(duì)應(yīng) test/release 。當(dāng)項(xiàng)目發(fā)布時(shí)為r ，當(dāng)項(xiàng)目提交測試時(shí)為t，t/r5數(shù)值基數(shù)為 0，以發(fā)布 /測試提交順序遞增加1 。6. yyyymmdd 代表生成版本的實(shí)際年月日，如：版本基線定義公司首次采用版本管理規(guī)范時(shí)，可以采取下列方法定義一個(gè)基線版本。獲取各項(xiàng)目最新的源程序、配置文件和文檔，形成發(fā)布分支、測試分支和開發(fā)分支。對(duì)每個(gè)項(xiàng)目的提測和發(fā)布分支都生成一個(gè)版本基線，如：。. 第五章版本提交準(zhǔn)則提交之前先更新更新的原則是要隨時(shí)更新，隨時(shí)提交。當(dāng)完成了一個(gè)小功能，能夠通過編譯并且自己測試之后，謹(jǐn)慎地提交。

9、如果在修改的期間其他同事也更改了同一個(gè)文件，那么update 更新時(shí)會(huì)自動(dòng)進(jìn)行合并，如果修改的是同一行或者二者修改差異過大，那么合并時(shí)會(huì)產(chǎn)生沖突。這種情況就需要同之前的開發(fā)人員聯(lián)系，兩人一起協(xié)商解決合并沖突。解決合并沖突之后，還需要兩人一起測試，以保證解決沖突之后，各自的程序不會(huì)受到影響。在更新時(shí)注意所更新文件的列表，如果提交過程中產(chǎn)生了更新，則需要重新編譯并且再次完成單元測試，再進(jìn)行提交。這樣既能了解別人修改了哪些文件，同時(shí)也能避免合并錯(cuò)誤導(dǎo)致代碼有錯(cuò)。保持原子提交為確保在需要時(shí)可以隨時(shí)回溯代碼版本，每次提交的代碼只能包含實(shí)現(xiàn)一個(gè)獨(dú)立、完整功能所必需的代碼，不能夾帶提交其他與此功能不相關(guān)的代

10、碼。為盡早提交，也可以將此獨(dú)立、完整功能分解為若干小細(xì)節(jié)功能，分別開發(fā)并提交所必需的代碼，但必須確保多次提交的功能代碼組合在一起，完全實(shí)現(xiàn)此獨(dú)立、完整功能。僅提交自己修改的部分，最好不要一下子將整個(gè)項(xiàng)目提交。每完成一個(gè)獨(dú)立、完整的功能后，最好盡早提交，以免后續(xù)更改時(shí)出現(xiàn)bug，無法恢復(fù)到正常代碼。每次提交的間歇盡可能地短，以幾個(gè)小時(shí)的開發(fā)工作為宜。我們提倡多提交，也就能多為代碼添加上保險(xiǎn)。為做到盡早提交，在開發(fā)功能模塊的時(shí)候，先將功能分解成一個(gè)個(gè)獨(dú)立的、不可再分割的小細(xì)節(jié)功能，分別完成。每完成一個(gè)并通過單元測試，就提交一次。在修改bug 的時(shí)候，每修改掉一個(gè)bug 并且確認(rèn)修改了這個(gè)bug，也

11、就提交一次。不要提交本地自動(dòng)生成的文件一般配置管理員都會(huì)將項(xiàng)目中一些自動(dòng)生成的文件或者與本地配置環(huán)境有關(guān)的文件屏蔽提交（例如 eclipse中的.classpath文件等， visual studio中的.suo 文件，debug,release,obj等編譯文件夾及其下文件，以及其他的一些自動(dòng)生成，同編譯代碼無關(guān)的文件）。如果項(xiàng)目中沒有進(jìn)行這方面的配置來強(qiáng)行禁止提交這樣的文件，請(qǐng)自覺不要提交這樣的文件，如果不小心簽入了，需要從配置庫中刪除，以免其他同事在更新后就可能與本地的環(huán)境沖突從而影響大家的工作。不要提交不能通過編譯的代碼代碼在提交之前，首先要確認(rèn)自己能夠在本地編譯通過，并且代碼在提交前

12、已經(jīng)通過自己的單元測試。如果在代碼中使用了第三方類庫，要把相應(yīng)類庫文件統(tǒng)一存儲(chǔ)在代碼相應(yīng)目錄中并提交，以免項(xiàng)目組成員中有些成員可能沒有安裝相應(yīng)的第三方類庫，從而在更新代碼后引起代碼運(yùn)行錯(cuò)誤。不要提交自己不明白的代碼代碼在提交之后即被項(xiàng)目成員所分享。如果提交了不明白的代碼，自己看不懂，別人也看不懂，如果在以后出現(xiàn)了問題將會(huì)成為項(xiàng)目質(zhì)量的隱患。因此在引入任何第三方代碼之前，確保對(duì)這個(gè)代碼有一個(gè)很清晰的了解（必要時(shí)應(yīng)有對(duì)應(yīng)文檔說明）。并行開發(fā)（同一模塊）前溝通如果開發(fā)小組采用并行開發(fā)模式開發(fā)同一模塊功能，在開發(fā)前，需要對(duì)協(xié)作開發(fā)進(jìn)行合理的工作計(jì)劃與任務(wù)分配，讓小組成員相互間了解對(duì)方的工作計(jì)劃與工作內(nèi)

13、容。這樣能盡可能的減少在開發(fā)過程中可能出現(xiàn)的沖突，提高開發(fā)效率。同時(shí)也能夠在和成員的交流中發(fā)現(xiàn)自己之前設(shè)計(jì)的不足，完善自己的設(shè)計(jì)。對(duì)提交更新的信息采用明晰的標(biāo)注如果提交空的標(biāo)注或者不確切的標(biāo)注將會(huì)讓項(xiàng)目組中其他的成員不了解此次簽入動(dòng)作的背景情況（如新增 /修改簽入的原因是什么新增/修改什么內(nèi)容），項(xiàng)目經(jīng)理無法通過提交的標(biāo)注信息，清晰的掌握開發(fā)工作進(jìn)度細(xì)節(jié)進(jìn)度。沒有清晰標(biāo)注，甚至?xí)?duì)回溯代碼版本造成影響。所以，在提交工作時(shí)，要填寫明晰的標(biāo)注，能夠概要的描述所提交文件的信息， 讓項(xiàng)目組其他成員在看到標(biāo)注后不用詳細(xì)看代碼就能了解你所做的修改。統(tǒng)一的標(biāo)注格式為：簽入動(dòng)作 +”+”#” +標(biāo)識(shí) id+”;”+簽入內(nèi)容 +“;”+簽入原因 簽入動(dòng)作：+：表示增加了功能（新增功能）*：表示對(duì)某些功能進(jìn)行了更改（修改功能）-：表示刪除了文件，或者對(duì)某些功能進(jìn)行了裁剪，刪除，屏蔽（刪除功能）：表示修正 bug（修復(fù)功能缺陷）！：優(yōu)化功能代碼的執(zhí)行性能（代碼性能優(yōu)化）標(biāo)識(shí) id：id 值是從項(xiàng)目開發(fā)計(jì)劃