產品版本管理規範

1、配置的目錄結構 

每一個項目在配置庫中應擁有惟一的名稱。配置庫目錄結構與內部的目錄結構建議按下列格式建立。 
配置庫目錄結構規劃： 
┠tags(發佈) 
┃ ├v1.0.0_T1_2016909 
┃ ├v1.0.0.33899_T1_20161009 
┃ ├v1.0.0_R1_20161109 
┃ ├v1.1.0_T1_20170109 
┃ └v1.1.0_R1_20170209 
┠trunk(主版本) 
┃ └projectA 
┃ ├src 
┃ ├rel_doc 
┃ ├doc 
┃ ├tool 
┃ ├。。。 
┖branches(分支) 
├SY_ABC 
├TJ_ABC 
├WH_MOOC 
其中，項目內部的目錄結構： 
|–projectA 
|–src （保存該項目的源程序） 
|–doc （保存項目相關文檔） 
|–000.產品管理 （保存產品過程管理相關文檔） 
|–010.產品計劃 （保存產品計劃相關文檔） 
|–020.項目需求 （保存產品需求相關文檔） 
|–030.系統設計 （保存系統設計相關文檔） 
|–030.系統測試 （保存系統代碼測試相關文檔） 
|–040.系統實施 （保存系統部署實施相關文檔） 
|–050.系統運維 （保存系統運維文檔，包括培訓、用戶手冊等） 
|–060.技術資料 （保存項目技術文檔，包括第三方技術資料等） 
|–。。。 （保存項目過程管理相關文檔） 
|–tool （包括該項目特定的開發、編譯、測試等工具） 
2、分支(branch) 
建議使用分支來協同不一樣小組對同一個配置庫的使用，可按照如下方式進行分支的管理。 
解決方案創建三個分支，包括主版本開發(trunk)、分支版本開發(branches)和發佈(tags)。 
 主版本開發 
是全部分支版本的基準版本，主版本的開發分支。開發部門開發使用。 
 分版本開發 
主版本的分支版本，供開發部門開發使用。開發工程師若是以主版本爲基準，進行軟件項目開發，要先將trunk目錄下的代碼分支到branches目錄的一個子目錄，在那裏對代碼進行開發。多個主版本的分版本可經過在branches頂級目錄建立多個分支目錄來區分。 
 發佈 
測試和發佈專用分支，該分支代碼不容許任何形式的修改。每一個通過測試後的不一樣版本的代碼作快照放到此分支文件夾下。 
3、 權限管理 
應對配置庫的訪問權限進行管理，確保軟件系統的完整性和安全性。建議按以下方式進行管理。 
3.1. 開發工程師 
僅擁有本身所屬項目的add file、delete file、check out、check in權限，無目錄建立和刪除權限。開發工程師若想建立目錄，需向配置管理員申請。 
3.2. 測試工程師 
擁有每一個項目的測試分支的add file、delete file、check out、check in權限，無目錄建立和刪除權限，對於其餘分支只有只讀權限。 
3.3. 配置管理員 
擁有所有權限，但增刪項目和增刪目錄須要有產品負責人批准。 
3.4. 其餘人員 
若須要配置訪問權限，需經走公司審批流程批准，由配置管理員分配權限。 
四. 版本管理 
應對產品版本&源代碼的版本進行管理，確保版本的準確性和可追溯性。建議按以下方式進行管理。 
4.1. 版本維護 
軟件工程各階段產生的各類文檔和代碼，應及時並統一上載到配置庫由配置庫管理員統一管理。對於要修改的配置項，應從配置庫中檢出（check out）後修改，修改完畢後及時檢入（check in），並填寫修改的緣由和內容。配置項的歷史版本應保存在配置庫中。 
4.2. 分支遷移 
從開發分支到測試分支的遷移，由開發工程師操做。遷移的時機有： 
1. 當開發負責人提交測試申請時； 
2. 開發過程當中進行測試，修改好一個或多個bug，須要測試工程師驗證時。 
從測試分支到發佈分支的遷移，由配置庫管理員操做。遷移的時機有： 
1.當開發組提交上線申請時。 
對於每一個項目從測試分支到發佈分支的遷移，配置庫管理員要創建分支遷移日誌，並詳細記錄。 
4.3. 版本升級 
軟件系統遷移到發佈分支後，生成新的版本。 
每一個系統新的版本不只以分支形式存在於配置庫中，而且要以獨立壓縮包形式備份。 
版本的命名規則爲，version N1.N2.N3[.N4][_][T/R5]_YYYYMMDD 
1. N1是系統編號。當項目總體從新設計時，N1加1，基數爲1 
2. N2是模塊編號。當模塊從新設計時，N2加1，基數爲0 
3. N3是功能編號。當項目增長某一功能，或某一功能須要修改時，N3加1，基數爲0 
4. N4是BUG編號。當項目的BUG被修復時，N4加1，基數爲0 
5. T/R5中的T/R分別對應Test/Release。當項目發佈時爲R，當項目提交測試時爲T，T/R5數值基數爲0，以發佈/測試提交順序遞增長1 。 
6. YYYYMMDD表明生成版本的實際年月日，如：20160202 
4.4. 版本基線定義 
公司首次採用版本管理規範時，能夠採起下列方法定義一個基線版本。 
獲取各項目最新的源程序、配置文件和文檔，造成發佈分支、測試分支和開發分支。 
對每一個項目的提測和發佈分支都生成一個版本基線，如：v1.0.0_R1_20160202。 
5、版本提交準則 
5.1. 提交以前先更新 
更新的原則是要隨時更新，隨時提交。當完成了一個小功能，可以經過編譯而且本身測試以後，謹慎地提交。 
若是在修改的期間其餘同事也更改了同一個文件，那麼update更新時會自動進行合併，若是修改的是同一行或者兩者修改差別過大，那麼合併時會產生衝突。這種狀況就須要同以前的開發人員聯繫，兩人一塊兒協商解決合併衝突。解決合併衝突以後，還須要兩人一塊兒測試，以保證解決衝突以後，各自的程序不會受到影響。 
在更新時注意所更新文件的列表，若是提交過程當中產生了更新，則須要從新編譯而且再次完成單元測試，再進行提交。這樣既能瞭解別人修改了哪些文件，同時也能避免合併錯誤致使代碼有錯。 
5.2. 保持原子提交 
爲確保在須要時能夠隨時回溯代碼版本，每次提交的代碼只能包含實現一個獨立、完整功能所必需的代碼，不能夾帶提交其餘與此功能不相關的代碼。爲儘早提交，也能夠將此獨立、完整功能分解爲若干小細節功能，分別開發並提交所必需的代碼，但必須確保屢次提交的功能代碼組合在一塊兒，徹底實現此獨立、完整功能。 
僅提交本身修改的部分，最好不要一會兒將整個項目提交。 
每完成一個獨立、完整的功能後，最好儘早提交，以避免後續更改時出現bug，沒法恢復到正常代碼。 
每次提交的間歇儘量地短，以幾個小時的開發工做爲宜。咱們提倡多提交，也就能多爲代碼添加上保險。爲作到儘早提交，在開發功能模塊的時候，先將功能分解成一個個獨立的、不可再分割的小細節功能，分別完成。每完成一個並經過單元測試，就提交一次。在修改bug的時候，每修改掉一個bug而且確認修改了這個bug，也就提交一次。 
5.3. 不要提交本地自動生成的文件 
通常配置管理員都會將項目中一些自動生成的文件或者與本地配置環境有關的文件屏蔽提交（例如Eclipse中的.classpath文件等，Visual Studio中的.suo文件，Debug,Release,Obj等編譯文件夾及其下文件，以及其餘的一些自動生成，同編譯代碼無關的文件）。若是項目中沒有進行這方面的配置來強行禁止提交這樣的文件，請自覺不要提交這樣的文件，若是不當心簽入了，須要從配置庫中刪除，以避免其餘同事在更新後就可能與本地的環境衝突從而影響你們的工做。 
5.4. 不要提交不能經過編譯的代碼 
代碼在提交以前，首先要確認本身可以在本地編譯經過，而且代碼在提交前已經經過本身的單元測試。 
若是在代碼中使用了第三方類庫，要把相應類庫文件統一存儲在代碼相應目錄中並提交，以避免項目組成員中有些成員可能沒有安裝相應的第三方類庫，從而在更新代碼後引發代碼運行錯誤。 
5.5. 不要提交本身不明白的代碼 
代碼在提交以後即被項目成員所分享。若是提交了不明白的代碼，本身看不懂，別人也看不懂，若是在之後出現了問題將會成爲項目質量的隱患。所以在引入任何第三方代碼以前，確保對這個代碼有一個很清晰的瞭解（必要時應有對應文檔說明）。 
5.6. 並行開發（同一模塊）前溝通 
若是開發小組採用並行開發模式開發同一模塊功能，在開發前，須要對協做開發進行合理的工做計劃與任務分配，讓小組成員相互間瞭解對方的工做計劃與工做內容。這樣能儘量的減小在開發過程當中可能出現的衝突，提升開發效率。同時也可以在和成員的交流中發現本身以前設計的不足，完善本身的設計。 
5.7. 對提交更新的信息採用明晰的標註 
若是提交空的標註或者不確切的標註將會讓項目組中其餘的成員不瞭解這次簽入動做的背景狀況（如新增/修改簽入的緣由是什麼？新增/修改什麼內容？），項目經理沒法經過提交的標註信息，清晰的掌握開發工做進度細節進度。沒有清晰標註，甚至會對回溯代碼版本形成影響。因此，在提交工做時，要填寫明晰的標註，可以概要的描述所提交文件的信息，讓項目組其餘成員在看到標註後不用詳細看代碼就能瞭解你所作的修改。

統一的標註格式爲： 
簽入動做+」」+」#」 +標識ID+」;」+簽入內容+[「;」]+[簽入緣由] 
簽入動做： 
+：表示增長了功能（新增功能） 
*：表示對某些功能進行了更改（修改功能） 
-：表示刪除了文件，或者對某些功能進行了裁剪，刪除，屏蔽（刪除功能） 
^：表示修正bug（修復功能缺陷） 
！：優化功能代碼的執行性能（代碼性能優化） 
標識ID： 
ID值是從項目開發計劃中的WBS任務分解表中獲取，對應具體功能編號。 
簽入內容： 
對新增/修改/刪除 的內容進行簡單描述 
簽入緣由： 
對修改/刪除 的緣由進行簡單描述 
示例： 
+ #62235；新增房源審覈功能 
* #62236；將房源審覈的二級審覈修改成一級審覈；爲縮短業務流程長度，提升業務響應速度 
- #62237；刪除多餘功能；房源審覈由二級審覈改成一級審覈後刪除無用功能 
^ #108；房源主圖顯示尺寸控制爲300*300；房源主圖顯示尺寸撐大頁面