軟件源碼版本管理規(guī)范-預(yù)覽頁
【正文】 保在系統(tǒng)開發(fā)和實施過程中項目的完整性和一致性。3. 第三章 職責(zé) 配置庫管理員：負(fù)責(zé)配置庫的日常維護(hù)和管理；監(jiān)督開發(fā)及測試部門及時提交版本管理對象（即配置項）。 可行性研究報告 252。 設(shè)計說明書 252。 培訓(xùn)計劃 252。 存儲過程腳本 252。 測試報告 252。配置庫目錄結(jié)構(gòu)與項目內(nèi)部的目錄結(jié)構(gòu)建議按下列格式創(chuàng)建。 解決方案建立三個分支，包括主版本開發(fā)(trunk)、分支版本開發(fā)(branches)和發(fā)布(tags)。 252。 252。建議按如下方式進(jìn)行管理。 . 配置庫管理員 擁有全部權(quán)限，但增刪項目和增刪目錄需要有項目負(fù)責(zé)人批準(zhǔn)。 . 版本維護(hù) 軟件工程各階段產(chǎn)生的各種文檔和代碼，應(yīng)及時并統(tǒng)一上載到配置庫由配置庫管理員統(tǒng)一管理。遷移的時機(jī)有： 1. 當(dāng)開發(fā)負(fù)責(zé)人提交測試申請時； 2. 開發(fā)過程中進(jìn)行測試，修改好一個或多個bug，需要測試工程師驗證時。 . 版本升級 軟件系統(tǒng)遷移到發(fā)布分支后，生成新的版本。當(dāng)模塊重新設(shè)計時，N2加1，基數(shù)為0 3. N3是功能編號。 6. YYYYMMDD代表生成版本的實際年月日，如：20160202 . 版本基線定義 公司首次采用版本管理規(guī)范時，可以采取下列方法定義一個基線版本。當(dāng)完成了一個小功能，能夠通過編譯并且自己測試之后，謹(jǐn)慎地提交。 在更新時注意所更新文件的列表，如果提交過程中產(chǎn)生了更新，則需要重新編譯并且再次完成單元測試，再進(jìn)行提交。 僅提交自己修改的部分，最好不要一下子將整個項目提交。為做到盡早提交，在開發(fā)功能模塊的時候，先將功能分解成一個個獨(dú)立的、不可再分割的小細(xì)節(jié)功能，分別完成。如果項目中沒有進(jìn)行這方面的配置來強(qiáng)行禁止提交這樣的文件，請自覺不要提交這樣的文件，如果不小心簽入了，需要從配置庫中刪除，以免其他同事在更新后就可能與本地的環(huán)境沖突從而影響大家的工作。如果提交了不明白的代碼，自己看不懂，別人也看不懂，如果在以后出現(xiàn)了問題將會成為項目質(zhì)量的隱患。同時也能夠在和成員的交流中發(fā)現(xiàn)自己之前設(shè)計的不足，完善自己的設(shè)計。統(tǒng)一的標(biāo)注格式為： 簽入動作+””+”” +標(biāo)識ID+”。
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1