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

1、精選學習資料 - - - 歡迎下載精品學習資料軟件版本治理規(guī)范第一章目的本規(guī)范具體規(guī)定軟件項目版本治理的對象.儲備目錄.分支.權(quán)限.保護等內(nèi)容,使 軟件項目版本治理流程化并規(guī)范化,確保在系統(tǒng)開發(fā)和實施過程中項目的完整性和一樣性；1.其次章適用范疇全部系統(tǒng)開發(fā)及實施項目的軟件項目都應(yīng)進行版本治理；項目中全部正式文檔和代碼都應(yīng)納入配置庫（可使用工具建立配置庫,本文所述使用的為svn ）進行版本治理；2.第三章職責配置庫治理員：負責配置庫的日常保護和治理；監(jiān)督開發(fā)及測試部門準時提交版本治理對象（即配置項）；此崗位可由開發(fā)或測試人員兼任；3.第四章內(nèi)容4.1. 版本治理對象包括但不限于：項目總體方案可

2、行性討論報告開發(fā)方案需求說明書精選學習資料 - - - 歡迎下載精品學習資料需求設(shè)計原型設(shè)計說明書系統(tǒng)開發(fā)變更申請單系統(tǒng)治理手冊用戶操作手冊培訓方案培訓記錄源程序支持系統(tǒng)運行的配置文件儲備過程腳本測試方案測試用例測試腳本測試報告上線方案上線申請版本保護日志4.2. 配置庫的目錄結(jié)構(gòu)每個項目在配置庫中應(yīng)擁有唯獨的項目名稱；配置庫目錄結(jié)構(gòu)與項目內(nèi)部的目錄結(jié)構(gòu)建議按以下格式創(chuàng)建；精選學習資料 - - - 歡迎下載精品學習資料配置庫目錄結(jié)構(gòu)規(guī)劃：tags 發(fā)布v1.0.0_t1_2021909v1.0.0.33899_t1_20211009 v1.0.0_r1_20211109 v1.1.0_t1_2

3、0210109 v1.1.0_r1_20210209trunk 主版本 projectasrcmy_moocdoctool ；branches分支sy_abctj_abcwh_mooc其中,項目內(nèi)部的目錄結(jié)構(gòu)：| projecta精選學習資料 - - - 歡迎下載精品學習資料| src （儲存該項目的源程序）| doc（儲存項目相關(guān)文檔）| 000. 項目治理（儲存項目過程治理相關(guān)文檔）| 010. 項目方案（儲存項目方案相關(guān)文檔）| 020. 項目需求（儲存項目需求相關(guān)文檔）| 030. 系統(tǒng)設(shè)計（儲存項目設(shè)計相關(guān)文檔）| 030. 系統(tǒng)測試（儲存項目代碼測試相關(guān)文檔）| 040. 系統(tǒng)實施

4、（儲存項目部署實施相關(guān)文檔）| 050. 系統(tǒng)運維（儲存項目運維文檔,包括培訓.用戶手冊等）| 060. 技術(shù)資料（儲存項目技術(shù)文檔,包括第三方技術(shù)資料等）|； （儲存項目過程治理相關(guān)文檔）| tool（包括該項目特定的開發(fā).編譯.測試等工具）4.3. 分支branch建議使用分支來協(xié)同不同職能小組對同一個配置庫的使用,可根據(jù)以下方式進行分支的治理；解決方案建立三個分支,包括主版本開發(fā)trunk .分支版本開發(fā) branches 和發(fā)布tags ；主版本開發(fā)為全部分支版本的基準版本,主版本的開發(fā)分支；開發(fā)部門開發(fā)使用；分版本開發(fā)精選學習資料 - - - 歡迎下載精品學習資料主版本的分支版本,供

5、開發(fā)部門開發(fā)使用；開發(fā)工程師假如以主版本為基準,進行軟件項目開發(fā),要先將trunk 目錄下的代碼分支到branches 目錄的一個子目錄,在那里對代碼進行開發(fā)；多個主版本的分版本可通過在branches頂級目錄創(chuàng)建多個分支目錄來區(qū)分；發(fā)布測試和發(fā)布專用分支,該分支代碼不答應(yīng)任何形式的修改；每個經(jīng)過測試后的不同版本的代碼做快照放到此分支文件夾下；4.4. 權(quán)限治理應(yīng)對配置庫的拜訪權(quán)限進行治理,確保軟件系統(tǒng)的完整性和安全性；建議按如下方式進行治理；4.4.1. 開發(fā)工程師僅擁有自己所屬項目的add file .delete file.check out.check in權(quán)限,無目錄創(chuàng)建和刪除權(quán)限；

6、開發(fā)工程師如想創(chuàng)建目錄,需向配置庫治理員申請；4.4.2. 測試工程師擁有每個項目的測試分支的add file .delete file.check out.check in權(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. 版本治理應(yīng)對軟件系統(tǒng)的版本進行治理,確保版本的精確性和可追溯性；建議按如下方式進行治理；4.5.1. 版本保護軟件工程各階

7、段產(chǎn)生的各種文檔和代碼,應(yīng)準時并統(tǒng)一上載到配置庫由配置庫治理員統(tǒng)一治理；對于要修改的配置項,應(yīng)從配置庫中檢出（check out ）后修改,修改完畢后準時檢入（ check in ）,并填寫修改的緣由和內(nèi)容；配置項的歷史版本應(yīng)儲存在配置庫中；4.5.2. 分支遷移從開發(fā)分支到測試分支的遷移,由開發(fā)工程師操作；遷移的時機有：1. 當開發(fā)負責人提交測試申請時；2. 開發(fā)過程中進行測試,修改好一個或多個bug ,需要測試工程師驗證時；從測試分支到發(fā)布分支的遷移,由配置庫治理員操作；遷移的時機有：1.當開發(fā)組提交上線申請時；對于每個項目從測試分支到發(fā)布分支的遷移,配置庫治理員要建立分支遷移日志,并具體

8、記錄；4.5.3. 版本升級軟件系統(tǒng)遷移到發(fā)布分支后,生成新的版本；每個系統(tǒng)新的版本不僅以分支形式存在于配置庫中,并且要以獨立壓縮包形式備份；精選學習資料 - - - 歡迎下載精品學習資料版本的命名規(guī)章為, version n1.n2.n3.n4_t/r5_yyyymmdd1. n1 為系統(tǒng)編號；當項目整體重新設(shè)計時,n1 加 1,基數(shù)為 12. n2 為模塊編號；當模塊重新設(shè)計時,n2 加 1,基數(shù)為 03. n3 為功能編號；當項目增加某一功能,或某一功能需要修改時,n3 加 1,基數(shù)為04. n4 為 bug 編號；當項目的 bug 被修復時, n4 加 1,基數(shù)為 05. t/r5 中

9、的 t/r 分別對應(yīng) test/release ；當項目發(fā)布時為r,當項目提交測試時為t,t/r5 數(shù)值基數(shù)為 0,以發(fā)布 / 測試提交次序遞增加1 ；6. yyyymmdd代表生成版本的實際年月日,如：202102024.5.4. 版本基線定義公司首次采納版本治理規(guī)范時,可以實行以下方法定義一個基線版本；獵取各項目最新的源程序.配置文件和文檔,形成發(fā)布分支.測試分支和開發(fā)分支；對每個項目的提測和發(fā)布分支都生成一個版本基線,如：version1.0.0_r1_20210202；4.6. 第五章版本提交準就4.6.1. 提交之前先更新更新的原就為要隨時更新,隨時提交；當完成了一個小功能,能夠通過

10、編譯并且自己測試之后,謹慎地提交；假如在修改的期間其他同事也更換了同一個文件,那么update更新時會自動進行合并,假如修改的為同一行或者二者修改差異過大,那么合并時會產(chǎn)生沖突；這種情形精選學習資料 - - - 歡迎下載精品學習資料就需要同之前的開發(fā)人員聯(lián)系,兩人一起協(xié)商解決合并沖突；解決合并沖突之后,仍需要兩人一起測試,以保證解決沖突之后,各自的程序不會受到影響；在更新時留意所更新文件的列表,假如提交過程中產(chǎn)生了更新,就需要重新編譯并且再次完成單元測試,再進行提交；這樣既能明白別人修改了哪些文件,同時也能防止合并錯誤導致代碼有錯；4.6.2. 保持原子提交為確保在需要時可以隨時回溯代碼版本,

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

12、過單元測試,就提交一次；在修改bug 的時候,每修改掉一個bug 并且確認修改了這個bug ,也就提交一次；4.6.3. 不要提交本地自動生成的文件一般配置治理員都會將項目中一些自動生成的文件或者與本地配置環(huán)境有關(guān)的文件精選學習資料 - - - 歡迎下載精品學習資料屏蔽提交（例如 eclipse 中的.classpath 文件等, visual studio中的.suo 文件,debug、release、obj等編譯文件夾及其下文件, 以及其他的一些自動生成, 同編譯代碼無關(guān)的文件）；假如項目中沒有進行這方面的配置來強行禁止提交這樣的文件,請自覺不要提交這樣的文件,假如不當心簽入了,需要從配置

13、庫中刪除,以免其他同事在更新后就可能與本地的環(huán)境沖突從而影響大家的工作；4.6.4. 不要提交不能通過編譯的代碼代碼在提交之前,第一要確認自己能夠在本地編譯通過,并且代碼在提交前已經(jīng)通過自己的單元測試；假如在代碼中使用了第三方類庫,要把相應(yīng)類庫文件統(tǒng)一儲備在代碼相應(yīng)目錄中并提交,以免項目組成員中有些成員可能沒有安裝相應(yīng)的第三方類庫,從而在更新代碼后引起代碼運行錯誤；4.6.5. 不要提交自己不明白的代碼代碼在提交之后即被項目成員所共享；假如提交了不明白的代碼,自己看不懂,別人也看不懂,假如在以后顯現(xiàn)了問題將會成為項目質(zhì)量的隱患；因此在引入任何第三方代碼之前,確保對這個代碼有一個很清楚的明白（必

14、要時應(yīng)有對應(yīng)文檔說明）；4.6.6. 并行開發(fā)（同一模塊）前溝通假如開發(fā)小組采納并行開發(fā)模式開發(fā)同一模塊功能,在開發(fā)前,需要對協(xié)作開發(fā)進行合理的工作方案與任務(wù)安排,讓小組成員相互間明白對方的工作方案與工作內(nèi)容；這樣能盡可能的削減在開發(fā)過程中可能顯現(xiàn)的沖突,提高開發(fā)效率；同時也能夠在和成員的溝通中發(fā)覺自己之前設(shè)計的不足,完善自己的設(shè)計；精選學習資料 - - - 歡迎下載精品學習資料4.6.7. 對提交更新的信息采納明晰的標注假如提交空的標注或者不準確的標注將會讓項目組中其他的成員不明白此次簽入動作的背景情形（如新增 /修改簽入的緣由為什么？新增/修改什么內(nèi)容？）,項目經(jīng)理無法通過提交的標注信息,

15、清楚的把握開發(fā)工作進度細節(jié)進度；沒有清楚標注,甚至會對回溯代碼版本造成影響；所以,在提交工作時,要填寫明晰的標注,能夠概要的描述所提交文件的信息, 讓項目組其他成員在看到標注后不用具體看代碼就能明白你所做的修改；統(tǒng)一的標注格式為：簽入動作 +” +”#” +標識 id+ ”;”+ 簽入內(nèi)容 + “;”+ 簽入緣由 簽入動作：+ ：表示增加了功能（新增功能）*：表示對某些功能進行了更換（修改功能）- ：表示刪除了文件,或者對某些功能進行了裁剪,刪除,屏蔽（刪除功能） ：表示修正 bug （修復功能缺陷）?。簝?yōu)化功能代碼的執(zhí)行性能（代碼性能優(yōu)化）標識 id：id 值為從項目開發(fā)方案中的wbs 任務(wù)分解