軟件版本管理制度

1、軟件版本理規(guī)范系統(tǒng)軟件開發(fā)部2011-9-20目錄1 引言 1.1 目的 1.2 范圍 1.3 術語定義1.4 版序控制記錄1.5 版本更新記錄2 版本管理2.1 流程圖 2.2 版本命名2.3 版本升級2.3.1 版本升級原則2.3.2 新版本的發(fā)布2.4 目錄結構2.5 文檔的存放2.5.1 文本文件的存放2.5.2 源代碼的存放2.5.3 發(fā)行文檔的存放 62.6 權限控制管理3 備份管理3.1 源文件備份3.2 庫文件備份4 用戶版本管理5 版本工具的使用5.1 配置管理工具5.2 CVS的使用5.2.1 常用命令5.2.2 簡單操作5.2.3 版本分支管理引言目的本文檔是為規(guī)范xxx

2、xxXt限公司軟件版本管理而制定的。范圍本文檔為系統(tǒng)軟件開發(fā)部版本管理員提供有關版本管理規(guī)范的相關內容，包括：版本標識方法軟件系統(tǒng)數據的存放文檔的修改控制文檔的備份制度術語定義CVSCV段一個開源的版本控制系統(tǒng) Concurrent Versions System勺簡稱文檔一種數據媒體和其上所記錄的數據。配置管理標識和確定系統(tǒng)中配置項的過程，在系統(tǒng)整個生存周期內控制這些項的投放和更動，記 錄并報告配置的狀態(tài)和更動要求，驗證配置項的完整性和正確性。軟件配置軟件的具體形態(tài)在某時刻的瞬時影像。配置項軟件配置管理的對象稱為配置項，如：系統(tǒng)規(guī)格說明書，項目開發(fā)計劃，用戶手冊，源碼 基線軟件生存周期中各開

3、發(fā)階段末尾的標記，它的作用是把各階段工作的劃分更加明確化，使 本來連續(xù)的工作在這些點上斷開，使之便于檢驗和肯定階段成果。版序控制記錄版序狀態(tài)擬稿審核批準發(fā)布日期1.0系統(tǒng)軟件開發(fā)部版本更新記錄*A -增加 M -修改 D -刪除版本/修訂版修改頁碼修改記錄修改人日期1.0初始版本版本管理 流程圖代碼歸檔流程代碼變更流程完成開發(fā)任務提交測試任務測試計劃、用例處理BUG更新測試環(huán)境1測試執(zhí)行回歸測試4r提交測試報告,提交發(fā)布請求r.確定版本信息 制做安裝程序新版本發(fā)布入庫 輸出給市場部 發(fā)布文檔更新流程說明：1、開發(fā)人員完成所負責模塊的代碼編寫任務后，提交到項目經理處2、項目經理向測試部門提交測試

4、任務3、配置管理員準備測試所需的環(huán)境4、測試人員開展測試并實時提交BUG5、開發(fā)人員處理測試過程中所出現(xiàn)的BUG,并提交給測試人員進行回歸測試，直至 BUG被關閉6、測試基本完成后，測試人員提交測試報告7、項目情況根據實際情況決定是否發(fā)布新的版本8、配置管理員與各相關人員經討論后確定好新版本各項信息9、配置管理員發(fā)布新版本 軟件版本命名軟件版本號由四部分組成，第一個1為主版本號，第二個1為子版本號，第三個1為階 段版本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本號共有5種，分別為：Alpha、Beta、RG Release例如：Beta。對于小項目或子系統(tǒng)而言，可簡化為 主版本號.

5、次版本號 .修訂版本號，如1.0.0。* 主版本號：當功能模塊有較大的變動，比如增加多個模塊或者整體架構發(fā)生變化。此 版本號由項目決定是否修改。* 子版本號：當功能有一定的增加或變化，比如增加了對權限控制、增加自定義視圖等 功能。此版本號由項目決定是否修改。* 階段版本號：一般是Bug修復或是一些小的變動，要經常發(fā)布修訂版，時間問隔不限， 修復一個嚴重的Bug即可發(fā)布一個修訂版。此版本號由項目經理決定是否修改。* 日期版本號用于記錄修改項目的當前日期，每天對項目的修改都需要更改日期版本號。 此版本號由開發(fā)人員決定是否修改。* Alpha版：此版本表示該軟件在此階段主要是以實現(xiàn)軟件功能為主，通常

6、只在軟件開發(fā) 者內部交流，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改。* Beta版：該版本相對于a版已有了很大的改進，消除了嚴重的錯誤，但還是存在著一些 缺陷，需要經過多次測試來進一步消除，此版本主要的修改對像是軟件的UI。* RC版：該版本已經相當成熟了，基本上不存在導致錯誤的BUG,與即將發(fā)行的正式版相 差無幾。* Release版：該版本意味 最終版本”，在前面版本的一系列測試版之后，終歸會有一個正 式版本，是最終交付用戶使用的一個版本。該版本有時也稱為標準版。一般情況下，Release不會以單詞形式出現(xiàn)在軟件封面上，取而代之的是符號（R）。版本升級 版本升級原則版本升級應嚴格納入

7、版本管理的控制之下。應當謹慎地控制版本的升級，保障高版本的向下 兼容性，或提供嚴格定義的升級方法。在下面幾種情況下，進行版本演化和升級：1、當產品發(fā)生重大修改和改進時，主版本號加1。重大修改和改進包括：1） 平臺遷移；2） 開發(fā)工具的遷移；3） 體系結構的變遷。2、當產品發(fā)生較小的改進或修改時，次版本號可以加 1。3、對于改動量比較少的，如修改產品的錯誤，可升級修訂版本號。4、記錄版本升級過程。每次版本升級，都要填寫版本升級記錄表，記錄表樣例如下： 版本升級記錄表主版本子系統(tǒng)名稱子系統(tǒng)版本發(fā)布日期功能變更描述發(fā)布責任人批準人備注說明：版本號：記錄當前發(fā)布的版本。發(fā)布日期：該版本批準發(fā)布的日期。

8、修改文件：版本修改記錄文件，一般為版本修改日志。 新版本的發(fā)布新版本的發(fā)布包括主版本號和次版本號的升級，一般不包括內部版本號的升級。流程如下：1、 根據項目進展情況，或者根據用戶需要進行發(fā)布準備。2、 將發(fā)布所需文件進行打包，放在指定目錄中，給目錄加上標簽Tag,標簽中包含將要發(fā)布的版本信息。3、 同樣對源碼文件也要加上與版本信息相關的標簽Tag=標簽Tag命名規(guī)則如下：組成：模塊首字母+下劃線+文件類型+下劃線+主版本號+次版本號+內部版本號+時間（+ 下劃線珀并標記）樣例：qzcj_src_1_0_0_110923 qzcj表示采集模塊的首字母，src表示源碼，1_0_0表示 將要發(fā)布的版

9、本號，合并標記可省略，只在有合并操作時注明，其中合并前的標記為 mbe,合并后的標記為maf。目錄結構但為了能更好地管理各項目組的文檔，建議可將被管理的配置項分為三大類：文檔類、 源碼類及安裝盤類，這樣存放比較清晰，有利于版本管理，現(xiàn)將目錄結構整理如下：根目錄一級目錄二級目錄對應配置項備注resp源碼code前置采集源碼后臺計算源碼業(yè)務應用源碼數據庫SQL文件業(yè)務支撐公用開發(fā)包文檔doc需求文檔立項報告、需求分析、需求 記錄設計文檔軟件架構、總體設計、概要 設計、詳細設計、界面設計數據庫文檔數據字典、數據庫搭建、備 份還原方案、PDM設計測試文檔測試計劃、測試用例、測試報告用戶文檔用戶手冊、產

10、品說明計劃文檔項目計劃、年度月度計劃外部接口文檔標準規(guī)范發(fā)布'義件SETUPreleaserar文件發(fā)布義檔二級目錄中的版本指一些特殊的版本，不影響基線版本文檔的存放文本文件的存放根據各項目部自己的情況，將系統(tǒng)用戶需求記錄、總體設計文檔、詳細設計及數據結構 文件、測試記錄、用戶手冊等放入 CVS倉庫doc目錄相應的子目錄下。源代碼的存放源代碼包括如：java, jsp, BMP, ICO等相關文件，是未經編譯處理的、不能直接交付使 用的產品文件以及編譯產品所需的文件；聯(lián)機幫助文件HLP在未生成HLP文件之前的DOC,RTF等格式的文檔也視為源代碼。各子系統(tǒng)當前的程序源文件放入 CV的庫

11、code目錄相應的bb目錄下，對于一個子系統(tǒng) 又分多個分子系統(tǒng)的情況，應在該目錄下分別建立幾個相應的子目錄。發(fā)行文檔的存放發(fā)行文檔是指產品交付用戶使用所必須的文件。包括：產品可執(zhí)行文件，用戶使用說明書，聯(lián)機幫助（HLP）;資源文件（BMP, ICO等），環(huán)境配置文件等。以上文檔作為制作發(fā)行盤的素材，放在 CVS倉庫發(fā)布文件目錄的Release目錄之下，制作好 的發(fā)行盤放在發(fā)布文件的Setup目錄。權限控制管理為保障文檔的安全性，一致性，以及防止意外修改，必須對不同的文檔設置不同的訪問權限。文檔權限類別：無任何權限，只讀權限，所有權限文檔類別：設計文檔，源碼，發(fā)行文檔。用戶類別：開發(fā)人員、測試人

12、員、項目經理、配置管理員等。為了控制不同的使用權限，根據要求在服務器上分別建立不同的用戶，針對不同的配置項所 在目錄分配不同的權限。為了便于管理，應以表格的形式列出人員與管理對象的訪問關系（用戶權限清單），詳 見系統(tǒng)部cvsa限配置。備份管理為了保證文檔的最大可恢復性，要隨時及定期地進行備份工作。 源文件備份開發(fā)人員每天都要將自已當日修改的源文件提交（commit）至CV的庫。庫文件備份為防止服務器出現(xiàn)異常，需對服務器上的 CVS倉庫文件進行備份，目前采用的方案如下： 工作日備份：每個工作日將原本位于 D盤的倉庫文件在H盤上備份一份，當D盤倉庫出現(xiàn)異 常時，用戶可把ROOT目錄修改至H盤備份的

13、目錄，再進行更新操作。每月備份：每個月底將最新版本備份至光盤。用戶版本管理為了更好地管理源程序，應為每一用戶建立一個用戶版本文件，該文件應包含以下內容：用戶編號：用戶名稱：軟件版本號：開始使用時間：聯(lián)系人：聯(lián)系電話：用戶程序更改日志樣例如下：更改 時間版本號修改模 塊名稱變更原因變更概述軟件位置變更 人員備注說明:1）用戶購買軟件時要為該用戶建立一個包含上述內容的一個用戶版本文件，并填寫有關數據。2）用戶進行版本更新時要求填寫該文件的版本變更記錄，用以反映用戶版本的變更情 況。版本工具的使用配置管理工具開發(fā)部采用CVS進行配置管理，CVS是一個C/S系統(tǒng)，多個開發(fā)人員通過一個中心版本 控制系統(tǒng)

14、來記錄，從而達到保證文件同步的目的。目前采用的CVS服務端為，客戶端為。CVS的使用常用命令英文命令中文而令操作、說明備注Checkout提取/取出將文件下載到本地目錄第一次下載目錄用Commit提交將改動過的文件提交到版本庫每次對文件更新后使用Update則將文件同步到最新版本秋取取新版本Tag標簽給某個版本添加一個標記符號便于合并分支與主線Branch分支創(chuàng)建某個文件的分支建立特殊版本時用到Merge合并將分支文件（或主文件）的更改合并到主文件（或 分支文件）diff比較不同比較任意兩個版本間的不同ReversionGraph版本分支圖查看文件各版本（包括分支文件）的走向圖查詢各個版本及

15、TagHistory歷史查看文件各個版本更新歷史查詢版本詳細信息簡單操作文件提?。撼醮问褂眯鑼⒃次募膫}庫提取出來，執(zhí)行 checkout命令將庫文件提取至本地相應位置定時更新：開發(fā)人員每天早上對源代碼或文件進行更新操作（右鍵執(zhí)行update操作）。實時更新：某一開發(fā)人員提交更改后，可通知其它人員進行更新操作。實時提交：對某一文件進行更改完成后，執(zhí)行 commit命令將更改提交至倉庫，更改前先進行更新操作，如多個 人員對同一文件同時進行操作，會產生沖突，這時需要對沖突進行處理。沖突處理：提交產生沖突時，先對文件進行同步（即更新）操作，之后會產生一個合并文件，'<號前為兩個版本相同

16、部分，號前為本地版本修改的內容，>'前為當前服務器最新版本修改的內容，找到最近提交該文件的同事，進行協(xié)商后對源文件進行修改并提交。創(chuàng)建分支/標簽：右鍵菜單中選擇Branch'或Tag'找開創(chuàng)建對tB框，輸入 Branch名或Tag名，選中Create new branch ' / 'Create new tag ',點擊 OK即可。查看版本/歷史：文件（非文件夾）右健菜單中選擇 Revision Graph.'或History.',可查看該文件的版本更 新記錄或歷史信息。版本分支管理我們把一個項目的主要開發(fā)過程稱作開發(fā)基線。

17、當某一個特殊事件發(fā)生的時候，例如，有一個用戶有特殊 的需求，于是就從這個開發(fā)基線里分離出來一個叉，以滿足用戶特殊的需求，這個叉有它自己的發(fā)展方向，這 就是分支。分支/-開發(fā)基線上面這個點，代表開發(fā)基線的最新版本，如果從開發(fā)基線建立分支來進行定制開發(fā)，開發(fā)基線和分支就可 以有各自的發(fā)展方向。如果有需要，分支的代碼可以重新合并到開發(fā)基線中，開發(fā)基線的代碼也可以合并到分 支代碼中。假設在我們的home目錄下的proj目錄就是我們的工程。下面具體看一下，如何建立分支：1、當我們要在基線某個版本建立分支時，先在基線該版本上創(chuàng)建一個標簽（Tag）,就是上圖中的黑點。這樣做是便于以后主干可以重新回到分支創(chuàng)建時的狀態(tài)。2、創(chuàng)建分支：右健單擊該目錄，選擇 Branch',指定分支名，點擊OK'即可。新建分支的版本號呈偶 數序列遞增，如在基線3、在另外的目錄下執(zhí)行 checkout命令，把剛才建立的分支提取出來（注意不要在原來目錄下提取，那樣 會覆蓋原有文件夾）。接下