軟件源碼版本管理規(guī)范標(biāo)準(zhǔn).doc

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

. . 軟件版本管理規(guī)范 1. 第一章　目的 本規(guī)范詳細(xì)規(guī)定軟件項(xiàng)目版本管理的對(duì)象、存儲(chǔ)目錄、分支、權(quán)限、維護(hù)等內(nèi)容，使軟件項(xiàng)目版本管理流程化并規(guī)范化，確保在系統(tǒng)開發(fā)和實(shí)施過程中項(xiàng)目的完整性和一致性。 2. 第二章　適用范圍 所有系統(tǒng)開發(fā)及實(shí)施項(xiàng)目的軟件項(xiàng)目都應(yīng)進(jìn)行版本管理。項(xiàng)目中所有正式文檔和代碼都應(yīng)納入配置庫(kù)（可使用工具建立配置庫(kù)，本文所述使用的是SVN）進(jìn)行版本管理。 3. 第三章　職責(zé) 配置庫(kù)管理員：負(fù)責(zé)配置庫(kù)的日常維護(hù)和管理；監(jiān)督開發(fā)及測(cè)試部門及時(shí)提交版本管理對(duì)象（即配置項(xiàng)）。 此崗位可由開發(fā)或測(cè)試人員兼任。 4. 第四章　內(nèi)容 4.1. 版本管理對(duì)象 包括但不限于： 項(xiàng)目總體計(jì)劃 可行性研究報(bào)告 開發(fā)計(jì)劃 需求說明書 需求設(shè)計(jì)原型 設(shè)計(jì)說明書 系統(tǒng)開發(fā)變更申請(qǐng)單 系統(tǒng)管理手冊(cè) 用戶操作手冊(cè) 培訓(xùn)計(jì)劃 培訓(xùn)記錄 源程序 支持系統(tǒng)運(yùn)行的配置文件 存儲(chǔ)過程腳本 測(cè)試計(jì)劃 測(cè)試用例 測(cè)試腳本 測(cè)試報(bào)告 上線計(jì)劃 上線申請(qǐng) 版本維護(hù)日志 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ī)劃： ┠tags(發(fā)布) ┃ ├v1.0.0_T1_2016909 ┃ ├v1.0.0.33899_T1_20161009 ┃ ├v1.0.0_R1_20161109 ┃ ├v1.1.0_T1_20170109 ┃ └v1.1.0_R1_20170209 ┠trunk(主版本) ┃ └projectA ┃ ├src ┃ ├MY_MOOC ┃ ├doc ┃ ├tool ┃ ├。。。 ┖branches(分支) ├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ā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)測(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ān)文檔） |–tool （包括該項(xiàng)目特定的開發(fā)、編譯、測(cè)試等工具） 4.3. 分支(branch) 建議使用分支來協(xié)同不同職能小組對(duì)同一個(gè)配置庫(kù)的使用，可按照以下方式進(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ā)布 測(cè)試和發(fā)布專用分支，該分支代碼不允許任何形式的修改。每個(gè)經(jīng)過測(cè)試后的不同版本的代碼做快照放到此分支文件夾下。 4.4. 權(quán)限管理 應(yīng)對(duì)配置庫(kù)的訪問權(quán)限進(jìn)行管理，確保軟件系統(tǒng)的完整性和安全性。建議按如下方式進(jìn)行管理。 4.4.1. 開發(fā)工程師 僅擁有自己所屬項(xiàng)目的add file、delete file、check out、check in權(quán)限，無目錄創(chuàng)建和刪除權(quán)限。開發(fā)工程師若想創(chuàng)建目錄，需向配置庫(kù)管理員申請(qǐng)。 4.4.2. 測(cè)試工程師 擁有每個(gè)項(xiàng)目的測(cè)試分支的add file、delete file、check out、check in權(quán)限，無目錄創(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ù)訪問權(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)確性和可追溯性。建議按如下方式進(jìn)行管理。 4.5.1. 版本維護(hù) 軟件工程各階段產(chǎn)生的各種文檔和代碼，應(yīng)及時(shí)并統(tǒng)一上載到配置庫(kù)由配置庫(kù)管理員統(tǒng)一管理。對(duì)于要修改的配置項(xiàng)，應(yīng)從配置庫(kù)中檢出（check out）后修改，修改完畢后及時(shí)檢入（check in），并填寫修改的原因和內(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ā)過程中進(jìn)行測(cè)試，修改好一個(gè)或多個(gè)bug，需要測(cè)試工程師驗(yàn)證時(shí)。 從測(cè)試分支到發(fā)布分支的遷移，由配置庫(kù)管理員操作。遷移的時(shí)機(jī)有： 1.當(dāng)開發(fā)組提交上線申請(qǐng)時(shí)。 對(duì)于每個(gè)項(xiàng)目從測(cè)試分支到發(fā)布分支的遷移，配置庫(kù)管理員要建立分支遷移日志，并詳細(xì)記錄。 4.5.3. 版本升級(jí) 軟件系統(tǒng)遷移到發(fā)布分支后，生成新的版本。 每個(gè)系統(tǒng)新的版本不僅以分支形式存在于配置庫(kù)中，并且要以獨(dú)立壓縮包形式備份。 版本的命名規(guī)則為，version N1.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是BUG編號(hào)。當(dāng)項(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. 提交之前先更新 更新的原則是要隨時(shí)更新，隨時(shí)提交。當(dāng)完成了一個(gè)小功能，能夠通過編譯并且自己測(cè)試之后，謹(jǐn)慎地提交。 如果在修改的期間其他同事也更改了同一個(gè)文件，那么update更新時(shí)會(huì)自動(dòng)進(jìn)行合并，如果修改的是同一行或者二者修改差異過大，那么合并時(shí)會(huì)產(chǎn)生沖突。這種情況就需要同之前的開發(fā)人員聯(lián)系，兩人一起協(xié)商解決合并沖突。解決合并沖突之后，還需要兩人一起測(cè)試，以保證解決沖突之后，各自的程序不會(huì)受到影響。 在更新時(shí)注意所更新文件的列表，如果提交過程中產(chǎn)生了更新，則需要重新編譯并且再次完成單元測(cè)試，再進(jìn)行提交。這樣既能了解別人修改了哪些文件，同時(shí)也能避免合并錯(cuò)誤導(dǎo)致代碼有錯(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，無法恢復(fù)到正常代碼。 每次提交的間歇盡可能地短，以幾個(gè)小時(shí)的開發(fā)工作為宜。我們提倡多提交，也就能多為代碼添加上保險(xiǎn)。為做到盡早提交，在開發(fā)功能模塊的時(shí)候，先將功能分解成一個(gè)個(gè)獨(dú)立的、不可再分割的小細(xì)節(jié)功能，分別完成。每完成一個(gè)并通過單元測(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文件等，Visual Studio中的.suo文件，Debug,Release,Obj等編譯文件夾及其下文件，以及其他的一些自動(dòng)生成，同編譯代碼無關(guān)的文件）。如果項(xiàng)目中沒有進(jìn)行這方面的配置來強(qiáng)行禁止提交這樣的文件，請(qǐng)自覺不要提交這樣的文件，如果不小心簽入了，需要從配置庫(kù)中刪除，以免其他同事在更新后就可能與本地的環(huán)境沖突從而影響大家的工作。 4.6.4. 不要提交不能通過編譯的代碼 代碼在提交之前，首先要確認(rèn)自己能夠在本地編譯通過，并且代碼在提交前已經(jīng)通過自己的單元測(cè)試。 如果在代碼中使用了第三方類庫(kù)，要把相應(yīng)類庫(kù)文件統(tǒng)一存儲(chǔ)在代碼相應(yīng)目錄中并提交，以免項(xiàng)目組成員中有些成員可能沒有安裝相應(yīng)的第三方類庫(kù)，從而在更新代碼后引起代碼運(yùn)行錯(cuò)誤。 4.6.5. 不要提交自己不明白的代碼 代碼在提交之后即被項(xiàng)目成員所分享。如果提交了不明白的代碼，自己看不懂，別人也看不懂，如果在以后出現(xiàn)了問題將會(huì)成為項(xiàng)目質(zhì)量的隱患。因此在引入任何第三方代碼之前，確保對(duì)這個(gè)代碼有一個(gè)很清晰的了解（必要時(shí)應(yīng)有對(duì)應(yīng)文檔說明）。 4.6.6. 并行開發(fā)（同一模塊）前溝通 如果開發(fā)小組采用并行開發(fā)模式開發(fā)同一模塊功能，在開發(fā)前，需要對(duì)協(xié)作開發(fā)進(jìn)行合理的工作計(jì)劃與任務(wù)分配，讓小組成員相互間了解對(duì)方的工作計(jì)劃與工作內(nèi)容。這樣能盡可能的減少在開發(fā)過程中可能出現(xiàn)的沖突，提高開發(fā)效率。同時(shí)也能夠在和成員的交流中發(fā)現(xiàn)自己之前設(shè)計(jì)的不足，完善自己的設(shè)計(jì)。 4.6.7. 對(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ì)劃中的WBS任務(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í)審核后刪除無用功能 ^ #108；房源主圖顯示尺寸控制為300*300；房源主圖顯示尺寸撐大頁面。 歡迎您的光臨，Word文檔下載后可修改編輯.雙擊可刪除頁眉頁腳.謝謝！希望您提出您寶貴的意見，你的意見是我進(jìn)步的動(dòng)力。贈(zèng)語； 1、如果我們做與不做都會(huì)有人笑，如果做不好與做得好還會(huì)有人笑，那么我們索性就做得更好，來給人笑吧！ 2、現(xiàn)在你不玩命的學(xué)，以后命玩你。3、我不知道年少輕狂，我只知道勝者為王。4、不要做金錢、權(quán)利的奴隸；應(yīng)學(xué)會(huì)做“金錢、權(quán)利”的主人。5、什么時(shí)候離光明最近？那就是你覺得黑暗太黑的時(shí)候。6、最值得欣賞的風(fēng)景，是自己奮斗的足跡。7、壓力不是有人比你努力，而是那些比你牛幾倍的人依然比你努力。 Word格式