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

.軟件版本管理目錄1.引言11.1.目的11.2.范圍11.3.術(shù)語定義11.4.參考資料21.5.版本控制記錄21.6.版本更新記錄22.版本管理42.1.版本標(biāo)示方法42.1.1.正式版本42.2.目錄結(jié)構(gòu)52.3.文檔的存放62.3.1.開發(fā)文檔的存放62.3.2.源代碼的存放62.3.3.SQL的語句存放72.3.4.發(fā)行文檔的存放72.4.配置管理流程72.5.權(quán)限控制的管理83.更新管理93.1.源程序的修改93.2.版本升級103.2.1.版本升級原則103.2.2.新版本發(fā)布113.3.文檔的變更114.備份管理12精選word范本！1. 引言版本控制就是對軟件開發(fā)過程中所創(chuàng)建的配置對象不同版本進(jìn)行管理，保證任何時(shí)間都可以取到正確的版本以及版本的組合。版本控制的主要功能是記錄開發(fā)過程中的每一次修改，讓開發(fā)的工作可以隨時(shí)檢查過往歷史記錄和獲得正確版本，是系統(tǒng)的成長記錄。1.1. 目的本文檔的編制是為了規(guī)范產(chǎn)品部、研發(fā)部、測試部對軟件產(chǎn)品版本的管理。1.2. 范圍本文檔為產(chǎn)品部、研發(fā)部、測試部的管理員提供有關(guān)版本管理規(guī)范的相關(guān)內(nèi)容，包括：l 版本標(biāo)識方法l 軟件系統(tǒng)數(shù)據(jù)的存放l 文檔的修改控制l 文檔的備份制度1.3. 術(shù)語定義SCM 軟件配置管理（Software Configuration Management）縮寫SVM軟件版本管理（Software Version Management）縮寫SVN一個(gè)開源的版本控制系統(tǒng)Subversion.文檔一種數(shù)據(jù)媒體和其上所記錄的數(shù)據(jù)。配置管理標(biāo)識和確定系統(tǒng)中配置項(xiàng)的過程，在系統(tǒng)整個(gè)生存周期內(nèi)控制這些項(xiàng)的投放和更動(dòng)，記錄并報(bào)告配置的狀態(tài)和更動(dòng)要求，驗(yàn)證配置項(xiàng)的完整性和正確性。軟件配置 軟件的具體形態(tài)在某時(shí)刻的瞬時(shí)影像。配置項(xiàng) 軟件配置管理的對象稱為配置項(xiàng)，如：系統(tǒng)規(guī)格說明書，項(xiàng)目開發(fā)計(jì)劃，用戶手冊，源碼?；€ 軟件生存周期中各開發(fā)階段末尾的標(biāo)記，它的作用是把各階段工作的劃分更加明確化，使本來連續(xù)的工作在這些點(diǎn)上斷開，使之便于檢驗(yàn)和肯定階段成果。1.4. 參考資料軟件版本管理規(guī)范 浪潮集團(tuán)山東通用軟件有限公司泰豪軟件開發(fā)軟件版本管理制度tortoise SVN的使用手冊1.5. 版本控制記錄版序狀態(tài)部門擬稿審核批準(zhǔn)發(fā)布日期1.01.6. 版本更新記錄*A - 增加 M - 修改 D - 刪除版本/修訂版修改頁碼修改記錄修改人日期1.0初始版本2. 版本管理2.1. 版本標(biāo)示方法為了使工作規(guī)范化、統(tǒng)一化，研發(fā)本部各部門實(shí)行的版本標(biāo)識管理方法。2.1.1. 正式版本軟件版本號由四部分組成，X.Y.Z.DATA_希臘字母，X：主版本號，用來表示提供給客戶的產(chǎn)品功能的主要增強(qiáng)。在一個(gè)極端的例子中，主版本號的上升用來說明產(chǎn)品現(xiàn)在已經(jīng)擁有了一個(gè)全新的功能類。從市場和許可權(quán)的角度來看，主版本號的升級相當(dāng)于購買一個(gè)完全獨(dú)立的產(chǎn)品。從開發(fā)者角度來看，一個(gè)主版本號的迭代差不多總是反映了一個(gè)新的獨(dú)立分支或是其主干還可以延續(xù)主版本的生命期。 Y：特征版本號，用來表示產(chǎn)品新增了一些特征，或者是在原來文檔中描述的特征上作了重要的修改。用來確定特征版本號什么時(shí)候需要修改的一個(gè)衡量標(biāo)準(zhǔn)就是產(chǎn)品功能說明書。產(chǎn)品的特征版本升級是在主版本之間保持產(chǎn)品競爭力的一種重要機(jī)制。 Z：缺陷修復(fù)版本號，用來表示在該版本上所做的缺陷維護(hù)行為的等級。版修復(fù)版本是穩(wěn)定市場和最小化客戶技術(shù)支持費(fèi)用負(fù)擔(dān)的一種重要機(jī)制。Alpha版: 此版本表示該軟件在此階段主要是以實(shí)現(xiàn)軟件功能為主，通常只在軟件開發(fā)者內(nèi)部交流，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改。Beta版: 該版本相對于版已有了很大的改進(jìn)，消除了嚴(yán)重的錯(cuò)誤，但還是存在著一些缺陷，需要經(jīng)過多次測試來進(jìn)一步消除，此版本主要的修改對像是軟件的UI。RC版: 該版本已經(jīng)相當(dāng)成熟了，基本上不存在導(dǎo)致錯(cuò)誤的BUG，與即將發(fā)行的正式版相差無幾。Release版: 該版本意味“最終版本”，在前面版本的一系列測試版之后，終歸會(huì)有一個(gè)正式版本，是最終交付用戶使用的一個(gè)版本。該版本有時(shí)也稱為標(biāo)準(zhǔn)版。一般情況下，Release不會(huì)以單詞形式出現(xiàn)在軟件封面上，取而代之的是符號(R)。例如：1.1.1.051021_beta.第一個(gè)1為主版本號，第二個(gè)1為子版本號，第三個(gè)1為階段版本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本號共有5種，分別為：base、alpha、beta、RC、release。2.2. 目錄結(jié)構(gòu)由于各部門的實(shí)際情況不同，目錄結(jié)構(gòu)很難統(tǒng)一，但為了能更好地管理各部門部文檔，建議可將被管理的配置項(xiàng)分為三大類：文檔類、源碼類及安裝盤類，這樣存放比較清晰，有利于版本管理。具體目錄如下表格所示：根目錄一級目錄二級目錄三級目錄項(xiàng)目名稱+版本號源代碼（SRC）集成代碼代碼的合并第一個(gè)模塊代碼第二個(gè)模塊代碼數(shù)據(jù)庫SQL公共開發(fā)包代碼文檔(DOC)立項(xiàng)文檔立項(xiàng)計(jì)劃書 立項(xiàng)申請書項(xiàng)目計(jì)劃項(xiàng)目開發(fā)計(jì)劃需求文檔需求規(guī)格說明書設(shè)計(jì)文檔設(shè)計(jì)概要說明書 數(shù)據(jù)庫設(shè)計(jì)說明書界面布局原型界面 動(dòng)態(tài)頁面參考資料項(xiàng)目一些參考資料驗(yàn)收文檔驗(yàn)收資料測試文檔測試計(jì)劃 測試報(bào)告 測試用例試用信息測試部署部署材料發(fā)布（RELEASE）SETUPRELEASE發(fā)布文檔2.3. 文檔的存放2.3.1. 開發(fā)文檔的存放文檔歸檔流程：2.3.2. 源代碼的存放2.3.3. SQL的語句存放各子系統(tǒng)SQL文件放入.SQL下，對于不同的數(shù)據(jù)庫，分別建立不同的子目錄，如WAT、SYB、MSS、ORC、DB2等。公共SQL文件直接放入SQL下即可，不同數(shù)據(jù)庫的特殊SQL分別放入對應(yīng)的子目錄下。2.3.4. 發(fā)行文檔的存放發(fā)行文檔是指產(chǎn)品交付用戶使用所必須的文件。包括：產(chǎn)品可執(zhí)行文件，用戶使用說明書，聯(lián)機(jī)幫助（HLP）；資源文件（BMP，ICO等），環(huán)境配置文件等。2.4. 配置管理流程流程說明：1. 開發(fā)人員完成所負(fù)責(zé)代碼模塊的編寫任務(wù)后，提交到項(xiàng)目經(jīng)理處；2. 項(xiàng)目經(jīng)理向測試部提交測試任務(wù)；3. 配置管理員準(zhǔn)備測試所需環(huán)境；4. 測試員開始測試并提供實(shí)時(shí)測試BUG；5. 開發(fā)人員處理測試人員提供的BUG，并提交測試員進(jìn)行回歸測試，直至BUG關(guān)閉；6. 測試完成后，測試人員提供測試報(bào)告；7. 根據(jù)項(xiàng)目情況決定是否發(fā)布新版本；8. 配置管理員與各成員確定好新版本的各項(xiàng)信息；9. 配置管理員發(fā)布新版本。2.5. 權(quán)限控制的管理為保障文檔的安全性，一致性，以及防止意外修改，必須對不同的文檔設(shè)置不同的訪問權(quán)限。文檔權(quán)限類別：只讀權(quán)限，讀寫權(quán)限。文檔類別：DOC，SRD，RELEASE。用戶類別：開發(fā)人員、測試人員、分析設(shè)計(jì)人員、部門經(jīng)理、配置管理員、安裝盤制作人員、問題及需求管理人員、用戶文檔編寫人員等。為了控制不同的使用權(quán)限，根據(jù)要求在服務(wù)器上分別建立不同的用戶，針對不同的配置項(xiàng)所在目錄分配不同的權(quán)限。為了便于各部門的管理，應(yīng)以表格的形式列出人員與管理對象的訪問關(guān)系（用戶權(quán)限清單）。3. 更新管理3.1. 源程序的修改當(dāng)開發(fā)小組在開發(fā)同一產(chǎn)品時(shí)，應(yīng)能保障：各成員間的修改不會(huì)互相覆蓋；程序員的修改能及時(shí)反映到產(chǎn)品的最新版本中。建議首先在相應(yīng)子系統(tǒng)的下一級建一目錄，如checkout，存放正在修改的文檔及修改登記表。當(dāng)某個(gè)程序員要修改某一文檔時(shí)，遵循以下程序：1) 接收維護(hù)任務(wù)；2) 查看需要修改的文件（如PBL及SQL等）是否正在被其它人員修改（檢查checkout目錄下是否存在要修改的文件或后綴已改為該程序員姓名簡寫）；3) 如果有人在修改該文件，等待或與相應(yīng)的開發(fā)員聯(lián)系，重復(fù)2。否則繼續(xù)；4) 將該文件復(fù)制到checkout目錄下，在修改登記表中登記；或?qū)⒃撐募暮缶Y改為本人姓名簡寫；5) 將該文件拷貝到自己的私有目錄；6) 根據(jù)要求修改源文件；7) 根據(jù)要求測試，并進(jìn)行相關(guān)項(xiàng)的回歸測試；8) 交測試人員測試，如未通過，重復(fù)6，如通過則繼續(xù)；9) 在checkout目錄中刪除該文件，并在修改登記表中標(biāo)注修改完成； 10) 將修改完畢的文件通過電子郵件或其它手段送交版本管理員，版本管理員將文件復(fù)制到相應(yīng)的路徑；如遇特殊情況（版本管理員出差），程序員可將修改完畢的文件復(fù)制到相應(yīng)的路徑下，或?qū)⒑缶Y改回正式。11) 回復(fù)下達(dá)者，報(bào)告維護(hù)任務(wù)完成。3.2. 版本升級3.2.1. 版本升級原則版本升級應(yīng)嚴(yán)格納入版本管理的控制之下。應(yīng)當(dāng)謹(jǐn)慎地控制版本的升級，保障高版本的向下兼容性，或提供嚴(yán)格定義的升級方法。主版本號(1)：當(dāng)功能模塊有較大的變動(dòng)，比如增加多個(gè)模塊或者整體架構(gòu)發(fā)生變化。此版本號由項(xiàng)目決定是否修改。子版本號(1)：當(dāng)功能有一定的增加或變化，比如增加了對權(quán)限控制、增加自定義視圖等功能。此版本號由項(xiàng)目決定是否修改。階段版本號(1)：一般是 Bug 修復(fù)或是一些小的變動(dòng)，要經(jīng)常發(fā)布修訂版，時(shí)間間隔不限，修復(fù)一個(gè)嚴(yán)重的bug即可發(fā)布一個(gè)修訂版。此版本號由項(xiàng)目經(jīng)理決定是否修改。日期版本號(140606):用于記錄修改項(xiàng)目的當(dāng)前日期，每天對項(xiàng)目的修改都需要更改日期版本號。此版本號由開發(fā)人員決定是否修改。希臘字母版本號(beta):此版本號用于標(biāo)注當(dāng)前版本的軟件處于哪個(gè)開發(fā)階段，當(dāng)軟件進(jìn)入到另一個(gè)階段時(shí)需要修改此版本號。此版本號由項(xiàng)目決定是否修改。 每次版本升級，要填寫版本升級記錄表，記錄表樣例如下：主版本號子系統(tǒng)名稱子系統(tǒng)版本發(fā)布日期變更功能描述發(fā)布人批準(zhǔn)人備注主版本號：記錄當(dāng)前發(fā)布的版本發(fā)布日期：該版本批準(zhǔn)發(fā)布的日期修改文件：版本修改記錄，版本修改日志3.2.2. 新版本發(fā)布新版本的發(fā)布包括主版本號和次版本號的升級，一般不包括內(nèi)部版本號的升級。流程如下：1) 接收新版本發(fā)布任務(wù)，接收本次發(fā)布的版本代號。2) 在指定目錄中，根據(jù)本次發(fā)布的版本號建立相應(yīng)的子目錄，將current下的所有內(nèi)容拷貝至新建目錄下。3) 可在新建目錄下建立readme.txt，并加入相應(yīng)的內(nèi)容。3.3. 文檔的變更文檔變更流程：4. 備份管理為了保證文檔的最大可恢復(fù)性，要隨時(shí)及定期地進(jìn)行備份工作。1) 隨時(shí)備份：1 開發(fā)人員每天都要將自已當(dāng)日修改的源文件在本地機(jī)器上進(jìn)