軟件源碼版本管理規(guī)范標準.doc

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

. . 軟件版本管理規(guī)范 1. 第一章　目的 本規(guī)范詳細規(guī)定軟件項目版本管理的對象、存儲目錄、分支、權限、維護等內(nèi)容，使軟件項目版本管理流程化并規(guī)范化，確保在系統(tǒng)開發(fā)和實施過程中項目的完整性和一致性。 2. 第二章　適用范圍 所有系統(tǒng)開發(fā)及實施項目的軟件項目都應進行版本管理。項目中所有正式文檔和代碼都應納入配置庫（可使用工具建立配置庫，本文所述使用的是SVN）進行版本管理。 3. 第三章　職責 配置庫管理員：負責配置庫的日常維護和管理；監(jiān)督開發(fā)及測試部門及時提交版本管理對象（即配置項）。 此崗位可由開發(fā)或測試人員兼任。 4. 第四章　內(nèi)容 4.1. 版本管理對象 包括但不限于： 項目總體計劃 可行性研究報告 開發(fā)計劃 需求說明書 需求設計原型 設計說明書 系統(tǒng)開發(fā)變更申請單 系統(tǒng)管理手冊 用戶操作手冊 培訓計劃 培訓記錄 源程序 支持系統(tǒng)運行的配置文件 存儲過程腳本 測試計劃 測試用例 測試腳本 測試報告 上線計劃 上線申請 版本維護日志 4.2. 配置庫的目錄結構 每個項目在配置庫中應擁有唯一的項目名稱。配置庫目錄結構與項目內(nèi)部的目錄結構建議按下列格式創(chuàng)建。 配置庫目錄結構規(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 其中，項目內(nèi)部的目錄結構： |–projectA |–src （保存該項目的源程序） |–doc （保存項目相關文檔） |–000.項目管理 （保存項目過程管理相關文檔） |–010.項目計劃 （保存項目計劃相關文檔） |–020.項目需求 （保存項目需求相關文檔） |–030.系統(tǒng)設計 （保存項目設計相關文檔） |–030.系統(tǒng)測試 （保存項目代碼測試相關文檔） |–040.系統(tǒng)實施 （保存項目部署實施相關文檔） |–050.系統(tǒng)運維 （保存項目運維文檔，包括培訓、用戶手冊等） |–060.技術資料 （保存項目技術文檔，包括第三方技術資料等） |–。。。 （保存項目過程管理相關文檔） |–tool （包括該項目特定的開發(fā)、編譯、測試等工具） 4.3. 分支(branch) 建議使用分支來協(xié)同不同職能小組對同一個配置庫的使用，可按照以下方式進行分支的管理。 解決方案建立三個分支，包括主版本開發(fā)(trunk)、分支版本開發(fā)(branches)和發(fā)布(tags)。 主版本開發(fā) 是所有分支版本的基準版本，主版本的開發(fā)分支。開發(fā)部門開發(fā)使用。 分版本開發(fā) 主版本的分支版本，供開發(fā)部門開發(fā)使用。開發(fā)工程師如果以主版本為基準，進行軟件項目開發(fā)，要先將trunk目錄下的代碼分支到branches目錄的一個子目錄，在那里對代碼進行開發(fā)。多個主版本的分版本可通過在branches頂級目錄創(chuàng)建多個分支目錄來區(qū)分。 發(fā)布 測試和發(fā)布專用分支，該分支代碼不允許任何形式的修改。每個經(jīng)過測試后的不同版本的代碼做快照放到此分支文件夾下。 4.4. 權限管理 應對配置庫的訪問權限進行管理，確保軟件系統(tǒng)的完整性和安全性。建議按如下方式進行管理。 4.4.1. 開發(fā)工程師 僅擁有自己所屬項目的add file、delete file、check out、check in權限，無目錄創(chuàng)建和刪除權限。開發(fā)工程師若想創(chuàng)建目錄，需向配置庫管理員申請。 4.4.2. 測試工程師 擁有每個項目的測試分支的add file、delete file、check out、check in權限，無目錄創(chuàng)建和刪除權限，對于其他分支只有只讀權限。 4.4.3. 配置庫管理員 擁有全部權限，但增刪項目和增刪目錄需要有項目負責人批準。 4.4.4. 其他人員 若需要配置庫訪問權限，需經(jīng)技術總監(jiān)或經(jīng)技術總監(jiān)授權的項目經(jīng)理批準，由配置庫管理員分配權限。 4.5. 版本管理 應對軟件系統(tǒng)的版本進行管理，確保版本的準確性和可追溯性。建議按如下方式進行管理。 4.5.1. 版本維護 軟件工程各階段產(chǎn)生的各種文檔和代碼，應及時并統(tǒng)一上載到配置庫由配置庫管理員統(tǒng)一管理。對于要修改的配置項，應從配置庫中檢出（check out）后修改，修改完畢后及時檢入（check in），并填寫修改的原因和內(nèi)容。配置項的歷史版本應保存在配置庫中。 4.5.2. 分支遷移 從開發(fā)分支到測試分支的遷移，由開發(fā)工程師操作。遷移的時機有： 1. 當開發(fā)負責人提交測試申請時； 2. 開發(fā)過程中進行測試，修改好一個或多個bug，需要測試工程師驗證時。 從測試分支到發(fā)布分支的遷移，由配置庫管理員操作。遷移的時機有： 1.當開發(fā)組提交上線申請時。 對于每個項目從測試分支到發(fā)布分支的遷移，配置庫管理員要建立分支遷移日志，并詳細記錄。 4.5.3. 版本升級 軟件系統(tǒng)遷移到發(fā)布分支后，生成新的版本。 每個系統(tǒng)新的版本不僅以分支形式存在于配置庫中，并且要以獨立壓縮包形式備份。 版本的命名規(guī)則為，version N1.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是BUG編號。當項目的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. 提交之前先更新 更新的原則是要隨時更新，隨時提交。當完成了一個小功能，能夠通過編譯并且自己測試之后，謹慎地提交。 如果在修改的期間其他同事也更改了同一個文件，那么update更新時會自動進行合并，如果修改的是同一行或者二者修改差異過大，那么合并時會產(chǎn)生沖突。這種情況就需要同之前的開發(fā)人員聯(lián)系，兩人一起協(xié)商解決合并沖突。解決合并沖突之后，還需要兩人一起測試，以保證解決沖突之后，各自的程序不會受到影響。 在更新時注意所更新文件的列表，如果提交過程中產(chǎn)生了更新，則需要重新編譯并且再次完成單元測試，再進行提交。這樣既能了解別人修改了哪些文件，同時也能避免合并錯誤導致代碼有錯。 4.6.2. 保持原子提交 為確保在需要時可以隨時回溯代碼版本，每次提交的代碼只能包含實現(xiàn)一個獨立、完整功能所必需的代碼，不能夾帶提交其他與此功能不相關的代碼。為盡早提交，也可以將此獨立、完整功能分解為若干小細節(jié)功能，分別開發(fā)并提交所必需的代碼，但必須確保多次提交的功能代碼組合在一起，完全實現(xiàn)此獨立、完整功能。 僅提交自己修改的部分，最好不要一下子將整個項目提交。 每完成一個獨立、完整的功能后，最好盡早提交，以免后續(xù)更改時出現(xiàn)bug，無法恢復到正常代碼。 每次提交的間歇盡可能地短，以幾個小時的開發(fā)工作為宜。我們提倡多提交，也就能多為代碼添加上保險。為做到盡早提交，在開發(fā)功能模塊的時候，先將功能分解成一個個獨立的、不可再分割的小細節(jié)功能，分別完成。每完成一個并通過單元測試，就提交一次。在修改bug的時候，每修改掉一個bug并且確認修改了這個bug，也就提交一次。 4.6.3. 不要提交本地自動生成的文件 一般配置管理員都會將項目中一些自動生成的文件或者與本地配置環(huán)境有關的文件屏蔽提交（例如Eclipse中的.classpath文件等，Visual Studio中的.suo文件，Debug,Release,Obj等編譯文件夾及其下文件，以及其他的一些自動生成，同編譯代碼無關的文件）。如果項目中沒有進行這方面的配置來強行禁止提交這樣的文件，請自覺不要提交這樣的文件，如果不小心簽入了，需要從配置庫中刪除，以免其他同事在更新后就可能與本地的環(huán)境沖突從而影響大家的工作。 4.6.4. 不要提交不能通過編譯的代碼 代碼在提交之前，首先要確認自己能夠在本地編譯通過，并且代碼在提交前已經(jīng)通過自己的單元測試。 如果在代碼中使用了第三方類庫，要把相應類庫文件統(tǒng)一存儲在代碼相應目錄中并提交，以免項目組成員中有些成員可能沒有安裝相應的第三方類庫，從而在更新代碼后引起代碼運行錯誤。 4.6.5. 不要提交自己不明白的代碼 代碼在提交之后即被項目成員所分享。如果提交了不明白的代碼，自己看不懂，別人也看不懂，如果在以后出現(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. 對提交更新的信息采用明晰的標注 如果提交空的標注或者不確切的標注將會讓項目組中其他的成員不了解此次簽入動作的背景情況（如新增/修改簽入的原因是什么？新增/修改什么內(nèi)容？），項目經(jīng)理無法通過提交的標注信息，清晰的掌握開發(fā)工作進度細節(jié)進度。沒有清晰標注，甚至會對回溯代碼版本造成影響。所以，在提交工作時，要填寫明晰的標注，能夠概要的描述所提交文件的信息，讓項目組其他成員在看到標注后不用詳細看代碼就能了解你所做的修改。 統(tǒng)一的標注格式為： 簽入動作+””+”#” +標識ID+”;”+簽入內(nèi)容+[“;”]+[簽入原因] 簽入動作： +：表示增加了功能（新增功能） *：表示對某些功能進行了更改（修改功能） -：表示刪除了文件，或者對某些功能進行了裁剪，刪除，屏蔽（刪除功能） ^：表示修正bug（修復功能缺陷） ?。簝?yōu)化功能代碼的執(zhí)行性能（代碼性能優(yōu)化） 標識ID： ID值是從項目開發(fā)計劃中的WBS任務分解表中獲取，對應具體功能編號。 簽入內(nèi)容： 對新增/修改/刪除 的內(nèi)容進行簡單描述 簽入原因： 對修改/刪除 的原因進行簡單描述 示例： + #62235；新增房源審核功能 * #62236；將房源審核的二級審核修改為一級審核；為縮短業(yè)務流程長度，提高業(yè)務響應速度 - #62237；刪除多余功能；房源審核由二級審核改為一級審核后刪除無用功能 ^ #108；房源主圖顯示尺寸控制為300*300；房源主圖顯示尺寸撐大頁面。 歡迎您的光臨，Word文檔下載后可修改編輯.雙擊可刪除頁眉頁腳.謝謝！希望您提出您寶貴的意見，你的意見是我進步的動力。贈語； 1、如果我們做與不做都會有人笑，如果做不好與做得好還會有人笑，那么我們索性就做得更好，來給人笑吧！ 2、現(xiàn)在你不玩命的學，以后命玩你。3、我不知道年少輕狂，我只知道勝者為王。4、不要做金錢、權利的奴隸；應學會做“金錢、權利”的主人。5、什么時候離光明最近？那就是你覺得黑暗太黑的時候。6、最值得欣賞的風景，是自己奮斗的足跡。7、壓力不是有人比你努力，而是那些比你牛幾倍的人依然比你努力。 Word格式