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

《軟件源碼版本管理規(guī)范》由會(huì)員分享，可在線閱讀，更多相關(guān)《軟件源碼版本管理規(guī)范（9頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

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

2、. 第四章內(nèi)容 4.1. 版本管理對(duì)象 包括但不限于： 項(xiàng)目總體計(jì)劃 可行性研究報(bào)告 開發(fā)計(jì)劃 需求說(shuō)明書 需求設(shè)計(jì)原型 設(shè)計(jì)說(shuō)明書 系統(tǒng)開發(fā)變更申請(qǐng)單 系統(tǒng)管理手冊(cè) 用戶操作手冊(cè) 培訓(xùn)計(jì)劃 培訓(xùn)記錄 源程序 支持系統(tǒng)運(yùn)行的配置文件存儲(chǔ)過(guò)程腳本測(cè)試計(jì)劃測(cè)試用例測(cè)試腳本測(cè)試報(bào)告上線計(jì)劃上線申請(qǐng)版本維護(hù)日志rBlu4。 4.2. 配置庫(kù)的目錄結(jié)構(gòu) 每個(gè)項(xiàng)目在配置庫(kù)中應(yīng)擁有唯一的項(xiàng)目名稱。配置庫(kù)目錄結(jié)構(gòu)與項(xiàng)目?jī)?nèi)部的目錄結(jié)構(gòu)建議按下列格式創(chuàng)建。 配置庫(kù)目錄結(jié)構(gòu)規(guī)劃： Hags（發(fā)布） |卜v1.0.0_T1_2016909 |卜v1.0O33899_T1_20

3、161009 |卜v1.0.0_R1_20161109 |卜v1.1.0_T1_20170109 ILv1.1.0_R1_20170209 Hrunk（主版本） IJprojectA I卜src IHmy_mooc I卜doc IHool |poooLbranches（分支）卜SY_ABC卜TJ_ABC WH_MOOC 其中，項(xiàng)目?jī)?nèi)部的目錄結(jié)構(gòu)： projectA src（保存該項(xiàng)目的源程序） doc（保存項(xiàng)目相關(guān)文檔） 000.項(xiàng)目管理（保存項(xiàng)目過(guò)程管理相關(guān)文檔） 010.項(xiàng)目計(jì)劃（保存項(xiàng)目計(jì)劃相關(guān)文檔） 020.項(xiàng)目需求（保存項(xiàng)目需求相關(guān)文檔） 03

4、0. 系統(tǒng)設(shè)計(jì) （保存項(xiàng)目設(shè)計(jì)相關(guān)文檔） 030. 系統(tǒng)測(cè)試 （保存項(xiàng)目代碼測(cè)試相關(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ò)程管理相關(guān)文檔） tool（包括該項(xiàng)目特定的開發(fā)、編譯、測(cè)試等工具） 4.3. 分支（branch） 建議使用分支來(lái)協(xié)同不同職能小組對(duì)同一個(gè)配置庫(kù)的使用，可按照以下方式進(jìn)行 分支的管理。 解決方案建立三個(gè)分支，包括主版本開發(fā)（trunk）、分支版本開發(fā)（branches）和 發(fā)布（tags）

5、。 主版本開發(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è)主版本的分版本可通過(guò)在branches頂級(jí)目錄 創(chuàng)建多個(gè)分支目錄來(lái)區(qū)分。 發(fā)布 每個(gè)經(jīng)過(guò)測(cè)試后的不 測(cè)試和發(fā)布專用分支，該分支代碼不允許任何形式的修改。 同版本的代碼做快照放到此分支文件夾下。 4.4. 權(quán)限管理 應(yīng)對(duì)配置庫(kù)的訪問(wèn)權(quán)限進(jìn)行管理，確保軟件系統(tǒng)的完整性和安全性。建議按如下 方式進(jìn)行管

6、理。 4.4.1. 開發(fā)工程師 僅擁有自己所屬項(xiàng)目的addout、checkin權(quán)限，無(wú)目錄創(chuàng)建和刪除權(quán)限。開 發(fā)工程師若想創(chuàng)建目錄，需向配置庫(kù)管理員申請(qǐng)。 4.4.2. 測(cè)試工程師 擁有每個(gè)項(xiàng)目的測(cè)試分支的addout、checkin權(quán)限，無(wú)目錄創(chuàng)建和刪除權(quán)限， 對(duì)于其他分支只有只讀權(quán)限。 4.4.3. 配置庫(kù)管理員 擁有全部權(quán)限，但增刪項(xiàng)目和增刪目錄需要有項(xiàng)目負(fù)責(zé)人批準(zhǔn)。 4.4.4. 其他人員 若需要配置庫(kù)訪問(wèn)權(quán)限，需經(jīng)技術(shù)總監(jiān)或經(jīng)技術(shù)總監(jiān)授權(quán)的項(xiàng)目經(jīng)理批準(zhǔn)，由配 置庫(kù)管理員分配權(quán)限。 4.5. 版本管理 應(yīng)對(duì)軟件系統(tǒng)的版本進(jìn)行管理，確保版本的準(zhǔn)確性和可追溯性。

7、建議按如下方式 進(jìn)行管理。 4.5.1. 版本維護(hù) 軟件工程各階段產(chǎn)生的各種文檔和代碼，應(yīng)及時(shí)并統(tǒng)一上載到配置庫(kù)由配置庫(kù)管 理員統(tǒng)一管理。對(duì)于要修改的配置項(xiàng)，應(yīng)從配置庫(kù)中檢出(checkout)后修改， 修改完畢后及時(shí)檢入(checkin)，并填寫修改的原因和內(nèi)容。配置項(xiàng)的歷史版 本應(yīng)保存在配置庫(kù)中。 4.5.2. 分支遷移 從開發(fā)分支到測(cè)試分支的遷移，由開發(fā)工程師操作。遷移的時(shí)機(jī)有： 1.當(dāng)開發(fā)負(fù)責(zé)人提交測(cè)試申請(qǐng)時(shí)； 2.開發(fā)過(guò)程中進(jìn)行測(cè)試，修改好一個(gè)或多個(gè)bug,需要測(cè)試工程師驗(yàn)證時(shí)。 從測(cè)試分支到發(fā)布分支的遷移，由配置庫(kù)管理員操作。遷移的時(shí)機(jī)有： 1.當(dāng)開發(fā)組提交

8、上線申請(qǐng)時(shí)。 對(duì)于每個(gè)項(xiàng)目從測(cè)試分支到發(fā)布分支的遷移，配置庫(kù)管理員要建立分支遷移日 志，并詳細(xì)記錄。 4.5.3. 版本升級(jí) 軟件系統(tǒng)遷移到發(fā)布分支后，生成新的版本。 每個(gè)系統(tǒng)新的版本不僅以分支形式存在于配置庫(kù)中，并且要以獨(dú)立壓縮包形式備 份。 版本的命名規(guī)則為，versionN1.N2.N3[.N4][_][T/R5]_YYYYMMDD 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是BU編號(hào)。當(dāng)

9、項(xiàng)目的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)目提交測(cè)試 時(shí)為T，T/R5數(shù)值基數(shù)為0，以發(fā)布/測(cè)試提交順序遞增加1。 6. YYYYMMDD表生成版本的實(shí)際年月日，如：20160202 4.5.4. 版本基線定義 公司首次采用版本管理規(guī)范時(shí)，可以采取下列方法定義一個(gè)基線版本。 獲取各項(xiàng)目最新的源程序、配置文件和文檔，形成發(fā)布分支、測(cè)試分支和開發(fā)分 支。 對(duì)每個(gè)項(xiàng)目的提測(cè)和發(fā)布分支都生成一個(gè)版本基線，如： Version1.0.0_R1_20160202。 4.6.第五章版本提交準(zhǔn)則 4.6.1.

10、 提交之前先更新 更新的原則是要隨時(shí)更新，隨時(shí)提交。當(dāng)完成了一個(gè)小功能，能夠通過(guò)編譯并且 自己測(cè)試之后，謹(jǐn)慎地提交。 如果在修改的期間其他同事也更改了同一個(gè)文件，那么update更新時(shí)會(huì)自動(dòng)進(jìn) 行合并，如果修改的是同一行或者二者修改差異過(guò)大，那么合并時(shí)會(huì)產(chǎn)生沖突。 這種情況就需要同之前的開發(fā)人員聯(lián)系，兩人一起協(xié)商解決合并沖突。解決合并 沖突之后，還需要兩人一起測(cè)試，以保證解決沖突之后，各自的程序不會(huì)受到影 響。 在更新時(shí)注意所更新文件的列表，如果提交過(guò)程中產(chǎn)生了更新，則需要重新編譯 并且再次完成單元測(cè)試，再進(jìn)行提交。這樣既能了解別人修改了哪些文件，同時(shí) 也能避免合并錯(cuò)誤導(dǎo)致

11、代碼有錯(cuò)。 4.6.2. 保持原子提交 為確保在需要時(shí)可以隨時(shí)回溯代碼版本，每次提交的代碼只能包含實(shí)現(xiàn)一個(gè)獨(dú) 立、完整功能所必需的代碼，不能夾帶提交其他與此功能不相關(guān)的代碼。為盡早 提交，也可以將此獨(dú)立、完整功能分解為若干小細(xì)節(jié)功能，分別開發(fā)并提交所必 需的代碼，但必須確保多次提交的功能代碼組合在一起，完全實(shí)現(xiàn)此獨(dú)立、完整 功能。 僅提交自己修改的部分，最好不要一下子將整個(gè)項(xiàng)目提交。 每完成一個(gè)獨(dú)立、完整的功能后，最好盡早提交，以免后續(xù)更改時(shí)出現(xiàn)bug,無(wú) 法恢復(fù)到正常代碼。 每次提交的間歇盡可能地短，以幾個(gè)小時(shí)的開發(fā)工作為宜。我們提倡多提交，也 就能多為代碼添加上保險(xiǎn)。

12、為做到盡早提交，在開發(fā)功能模塊的時(shí)候，先將功能 分解成一個(gè)個(gè)獨(dú)立的、不可再分割的小細(xì)節(jié)功能，分別完成。每完成一個(gè)并通過(guò) 單元測(cè)試，就提交一次。在修改bug的時(shí)候，每修改掉一個(gè)bug并且確認(rèn)修改了 這個(gè)bug,也就提交一次。 4.6.3. 不要提交本地自動(dòng)生成的文件 一般配置管理員都會(huì)將項(xiàng)目中一些自動(dòng)生成的文件或者與本地配置環(huán)境有關(guān)的 文件屏蔽提交（例如Eclipse中的.classpath文件等，VisualStudio中的.suo 文件，Debug,Release,Obj等編譯文件夾及其下文件，以及其他的一些自動(dòng)生成， 同編譯代碼無(wú)關(guān)的文件）。如果項(xiàng)目中沒有進(jìn)行這方面的配置來(lái)

13、強(qiáng)行禁止提交這 樣的文件，請(qǐng)自覺不要提交這樣的文件，如果不小心簽入了，需要從配置庫(kù)中刪 除，以免其他同事在更新后就可能與本地的環(huán)境沖突從而影響大家的工作。 4.6.4. 不要提交不能通過(guò)編譯的代碼 代碼在提交之前，首先要確認(rèn)自己能夠在本地編譯通過(guò)，并且代碼在提交前已經(jīng) 通過(guò)自己的單元測(cè)試。 如果在代碼中使用了第三方類庫(kù)，要把相應(yīng)類庫(kù)文件統(tǒng)一存儲(chǔ)在代碼相應(yīng)目錄中 并提交，以免項(xiàng)目組成員中有些成員可能沒有安裝相應(yīng)的第三方類庫(kù)，從而在更 新代碼后引起代碼運(yùn)行錯(cuò)誤。 4.6.5. 不要提交自己不明白的代碼 代碼在提交之后即被項(xiàng)目成員所分享。如果提交了不明白的代碼，自己看不懂， 別

14、人也看不懂，如果在以后出現(xiàn)了問(wèn)題將會(huì)成為項(xiàng)目質(zhì)量的隱患。因此在引入任 何第三方代碼之前，確保對(duì)這個(gè)代碼有一個(gè)很清晰的了解（必要時(shí)應(yīng)有對(duì)應(yīng)文檔 說(shuō)明）。 4.6.6. 并行開發(fā)（同一模塊）前溝通 如果開發(fā)小組采用并行開發(fā)模式開發(fā)同一模塊功能，在開發(fā)前，需要對(duì)協(xié)作開發(fā) 進(jìn)行合理的工作計(jì)劃與任務(wù)分配，讓小組成員相互間了解對(duì)方的工作計(jì)劃與工作 內(nèi)容。這樣能盡可能的減少在開發(fā)過(guò)程中可能出現(xiàn)的沖突，提高開發(fā)效率。同時(shí) 也能夠在和成員的交流中發(fā)現(xiàn)自己之前設(shè)計(jì)的不足，完善自己的設(shè)計(jì)。 4.6.7. 對(duì)提交更新的信息采用明晰的標(biāo)注 如果提交空的標(biāo)注或者不確切的標(biāo)注將會(huì)讓項(xiàng)目組中其他的成員不了解

15、此次簽 入動(dòng)作的背景情況（如新增/修改簽入的原因是什么？新增/修改什么內(nèi)容？）， 項(xiàng)目經(jīng)理無(wú)法通過(guò)提交的標(biāo)注信息，清晰的掌握開發(fā)工作進(jìn)度細(xì)節(jié)進(jìn)度。沒有清 晰標(biāo)注，甚至?xí)?duì)回溯代碼版本造成影響。所以，在提交工作時(shí)，要填寫明晰的 標(biāo)注，能夠概要的描述所提交文件的信息，讓項(xiàng)目組其他成員在看到標(biāo)注后不用 詳細(xì)看代碼就能了解你所做的修改。Bjc0p。 統(tǒng)一的標(biāo)注格式為： 簽入動(dòng)作+””+”#”+標(biāo)識(shí)ID+”;”+簽入內(nèi)容+[“;”]+[簽入原因] 簽入動(dòng)作： +：表示增加了功能（新增功能） *：表示對(duì)某些功能進(jìn)行了更改（修改功能） -：表示刪除了文件，或者對(duì)某些功能進(jìn)行了裁剪，刪除

16、，屏蔽（刪除功能） A：表示修正bug（修復(fù)功能缺陷） ！：優(yōu)化功能代碼的執(zhí)行性能（代碼性能優(yōu)化） 標(biāo)識(shí)ID： ID值是從項(xiàng)目開發(fā)計(jì)劃中的WBSE務(wù)分解表中獲取，對(duì)應(yīng)具體功能編號(hào)。 簽入內(nèi)容： 對(duì)新增/修改/刪除的內(nèi)容進(jìn)行簡(jiǎn)單描述 簽入原因： 對(duì)修改/刪除的原因進(jìn)行簡(jiǎn)單描述 示例： +#62235；新增房源審核功能 *#62236；將房源審核的二級(jí)審核修改為一級(jí)審核；為縮短業(yè)務(wù)流程長(zhǎng)度，提高 業(yè)務(wù)響應(yīng)速度 -#62237；刪除多余功能；房源審核由二級(jí)審核改為一級(jí)審核后刪除無(wú)用功能 A#108;房源主圖顯示尺寸控制為300*300;房源主圖顯示尺寸撐大頁(yè)面。Qib85。