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

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

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

2、. 第四章內(nèi)容 4.1. 版本管理對象 包括但不限于： 項目總體計劃 可行性研究報告 開發(fā)計劃 需求說明書 需求設計原型 設計說明書 系統(tǒng)開發(fā)變更申請單 系統(tǒng)管理手冊 用戶操作手冊 培訓計劃 培訓記錄 源程序 支持系統(tǒng)運行的配置文件存儲過程腳本測試計劃測試用例測試腳本測試報告上線計劃上線申請版本維護日志rBlu4。 4.2. 配置庫的目錄結(jié)構(gòu) 每個項目在配置庫中應擁有唯一的項目名稱。配置庫目錄結(jié)構(gòu)與項目內(nèi)部的目錄結(jié)構(gòu)建議按下列格式創(chuàng)建。 配置庫目錄結(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 其中，項目內(nèi)部的目錄結(jié)構(gòu)： projectA src（保存該項目的源程序） doc（保存項目相關(guān)文檔） 000.項目管理（保存項目過程管理相關(guān)文檔） 010.項目計劃（保存項目計劃相關(guān)文檔） 020.項目需求（保存項目需求相關(guān)文檔） 03

4、0. 系統(tǒng)設計 （保存項目設計相關(guān)文檔） 030. 系統(tǒng)測試 （保存項目代碼測試相關(guān)文檔） 040.系統(tǒng)實施（保存項目部署實施相關(guān)文檔） 050.系統(tǒng)運維（保存項目運維文檔，包括培訓、用戶手冊等） 060.技術(shù)資料（保存項目技術(shù)文檔，包括第三方技術(shù)資料等） （保存項目過程管理相關(guān)文檔） tool（包括該項目特定的開發(fā)、編譯、測試等工具） 4.3. 分支（branch） 建議使用分支來協(xié)同不同職能小組對同一個配置庫的使用，可按照以下方式進行 分支的管理。 解決方案建立三個分支，包括主版本開發(fā)（trunk）、分支版本開發(fā)（branches）和 發(fā)布（tags）

5、。 主版本開發(fā) 是所有分支版本的基準版本，主版本的開發(fā)分支。開發(fā)部門開發(fā)使用。 分版本開發(fā) 主版本的分支版本，供開發(fā)部門開發(fā)使用。開發(fā)工程師如果以主版本為基準，進 行軟件項目開發(fā)，要先將trunk目錄下的代碼分支到branches目錄的一個子目 錄，在那里對代碼進行開發(fā)。多個主版本的分版本可通過在branches頂級目錄 創(chuàng)建多個分支目錄來區(qū)分。 發(fā)布 每個經(jīng)過測試后的不 測試和發(fā)布專用分支，該分支代碼不允許任何形式的修改。 同版本的代碼做快照放到此分支文件夾下。 4.4. 權(quán)限管理 應對配置庫的訪問權(quán)限進行管理，確保軟件系統(tǒng)的完整性和安全性。建議按如下 方式進行管

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

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

8、上線申請時。 對于每個項目從測試分支到發(fā)布分支的遷移，配置庫管理員要建立分支遷移日 志，并詳細記錄。 4.5.3. 版本升級 軟件系統(tǒng)遷移到發(fā)布分支后，生成新的版本。 每個系統(tǒng)新的版本不僅以分支形式存在于配置庫中，并且要以獨立壓縮包形式備 份。 版本的命名規(guī)則為，versionN1.N2.N3[.N4][_][T/R5]_YYYYMMDD 1. N1是系統(tǒng)編號。當項目整體重新設計時，N1加1,基數(shù)為1 2. N2是模塊編號。當模塊重新設計時，N2加1,基數(shù)為0 3. N3是功能編號。當項目增加某一功能，或某一功能需要修改時，N3加1,基 數(shù)為0 4. N4是BU編號。當

9、項目的BUG?修復時，N4加1,基數(shù)為0 5. T/R5中的T/R分別對應Test/Release。當項目發(fā)布時為R,當項目提交測試 時為T，T/R5數(shù)值基數(shù)為0，以發(fā)布/測試提交順序遞增加1。 6. YYYYMMDD表生成版本的實際年月日，如：20160202 4.5.4. 版本基線定義 公司首次采用版本管理規(guī)范時，可以采取下列方法定義一個基線版本。 獲取各項目最新的源程序、配置文件和文檔，形成發(fā)布分支、測試分支和開發(fā)分 支。 對每個項目的提測和發(fā)布分支都生成一個版本基線，如： Version1.0.0_R1_20160202。 4.6.第五章版本提交準則 4.6.1.

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

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

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

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

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

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

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