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

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

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

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

4、試等工具）. 分支(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ā)布專用分支，該分支代碼不允許

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

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

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

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

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

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

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

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

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