產品版本規劃

    最近兄弟部門部門作了比較大的調整。須要從新去定義產品，並作好產品的版本規劃。從質量管理部OKR來分析，支持產品部門作好產品規劃也是個優先任務。

    （實際是之前沒有明確，達成約定的版本規劃和版本號定義…）

 

    一個好的產品規劃，除了對本身的產品有充分清晰地思考以外，還要兼顧外界的技術趨勢、業界的動態、公司資源的考量。必定不能盲目地去加各類各樣的需求，或者毫無目的地去作版本迭代。每一個版本的需求必定都是基於產品目前的現狀，市場的狀況，最後基於產品發展的目的而去作的。

    這是我總結的產品規劃流程圖：

由於對具體的產品業務不清楚，因此在職能擅長的範疇內，我會在產品版本命名規則，環境分層兩方面給與產品部門具體的支持和建議。

 

 

 

 

 

 

 

 

 

 

 

軟件版本號的命名規範與原則

爲了在軟件產品生命週期中更好的溝通和標記，不少公司對版本命名都有本身的一套規範，例如：

• <名稱>_<主版本號>.<子版本號>_<SVN最後提交數>
• <名稱>_<主版本號>.<子版本號>.<階段版本號>_<日期版本號加希臘字母版本號>
• <名稱>_<主版本號>.<子版本號>_<日期版本號加希臘字母版本號>

咱們應該對軟件的版本號命名的規範和原則有必定的瞭解。 

一、APP、軟件的版本階段

Alpha版：也叫α版，此版本主要是以實現軟件功能爲主，一般只在軟件開發者內部交流，通常而言，該版本軟件的Bug較多，須要繼續修改。

Beta版：此版本相對於α版已經有了很大的改進，消除了嚴重的錯誤，但仍是存在着一些缺陷，須要通過屢次測試來進一步消除，此版本主要的修改對像是軟件的UI。

RC版：此版本已經至關成熟了，基本上不存在致使錯誤的BUG，與即將發行的正式版相差無幾，測試人員基本經過的版本。

Release版：此版本意味着"最終版本"、"上線版本"，，在前面版本的一系列測試版以後，終歸會有一個正式版本，是最終交付用戶使用的一個版本。該版本有時也稱爲標準版。通常狀況下，Release不會以單詞形式出如今軟件封面上，取而代之的是符號(R)。

 

二、版本號的命名規範與原則

軟件版本號有四部分組成：<主版本號.><子版本號>.<階段版本號>.<日期版本號加希臘字母版本號>。希臘字母版本號共有5種：base、alpha、beta、RC、Release。 例如：1.0.0.180313_base 

一般，徹底的版本號定義，分三項： <主版本號.><子版本號>.<階段版本號>, 1.1.0

 

三、版本號修改規則

主版本號(1.x.x)：當功能模塊有較大的變更，好比增長多個模塊或者總體架構發生變化。此版本號由項目決定是否修改。

子版本號(x.1.x)：當功能有必定的增長或變化，好比增長了對權限控制、增長自定義視圖等功能。此版本號由項目決定是否修改。

階段版本號(x.x.1)：通常是 Bug 修復或是一些小的變更，要常常發佈更新版，時間間隔不限，修復一個嚴重的bug便可發佈一個修訂版。此版本號由項目經理決定是否修改。

日期版本號(x.x.x.180313)：用於記錄修改項目的當前日期，天天對項目的修改都須要更改日期版本號。此版本號由開發人員決定是否修改。

希臘字母版本號(x.x.x.x_beta):：此版本號用於標註當前版本的軟件處於哪一個開發階段，當軟件進入到另外一個階段時須要修改此版本號。此版本號由項目經理決定是否修改。

 

四、版本號的階段標識

    按照軟件的研發過程，能夠再將版本號進行相應的標註管理，但管理會變得過於複雜，視具體狀況而定！

 

五、關於APP的版本管理

    以Android爲例， Android中有 versionCode 和 versionName，他們分別所表明的意思以下：

verisonCode:內部版本號，必須是整型。用來區分版本的新舊，版本號越大，表明距當前越近的發佈版本。給開發者內部使用的。 

versionName:向用戶展現的版本號，必須是字符串，這個版本號就是咱們能夠用來遵循規範的位置，能夠做爲版本比較的，判斷是否須要提示更新、是否須要強制更新的依據。 

使用SCM進行代碼管理

公司使用的SCM系統是SVN，    如下結合SVN介紹怎樣進行代碼版本管理。

Subversion有一個很標準的目錄結構，是這樣的。好比項目是proj，svn地址爲svn://proj/，那麼標準的svn佈局是

   svn://proj/
   |
   +-trunk
   +-branches
   +-tags  

SVN有兩種廣泛的管理模式：

    以Trunk作開發：

全部的開發都是基於trunk進行開發

時間區間(1) 

• (1)的起始時間是1.0.0開發的開始。
• 在(1)期間，沒有任何用戶使用1.0.0（尚未發佈），開發人員直接在Trunk1.0.0上開發。
• (1)的結束時間是3.0開發的結束時間。結束時發佈1.0.0產品，在SVN上建立1.0.0 Tag。這時Trunk1.0.0自動變成Trunk 1.0.1。

時間區間(2) 

• (2)的起始時間是1.0.1開發的開始。
• 若是在(2)期間，用戶報告1.0.0的Bug或者一些很急迫的功能要求，而且須要立刻修復實現。那麼： 
  • 在Tag：1.0.0_release基礎上創建branches:1.0.0_bugfix，而且發佈補丁包。
  • 選擇性的把 dev_1.0.0_bugfix這個分支merge回trunk（何時進行這步操做，要根據具體狀況）
• (2)的結束時間是Turnk1.0.1開發的結束時間。結束時發佈1.0.1產品。此時作如下事情： 
  • 將branches:1.0.0_bugfix的代碼合併到Trunk1.0.1上。而且發佈鎖定Tag：1.0.1_release代碼避免任何進一步的修改。
  • 這時Trunk1.0.1自動變成Trunk 1.0.2。

 

 

 

 

 

 

 

 

 

 

 

以分支作開發：

時間區間(1) 

• (1)的起始時間是1.0.0開發的開始。
• 在(1)期間，沒有任何用戶使用1.0.0（尚未發佈），開發人員直接在Trunk1.0.0上開發。
• (1)的結束時間是3.0開發的結束時間。結束時發佈1.0.0產品，在SVN上建立1.0.0 Tag，同時建立1.0.1 Branch。這時Trunk1.0.0自動變成Trunk 1.0.1。

時間區間(2) 

• (2)的起始時間是1.0.1開發的開始。
• 在(2)期間，由於有用戶使用1.0.0，因此1.0.1全部的開發工做在Branch1.0.1上進行。
• 若是在(2)期間，用戶報告1.0.0的Bug，而且須要立刻修復。那麼： 
  • 在1.0.1 Trunk上對問題進行修復，而且發佈補丁包。
  • 將此改動合併到Branch1.0.1上。
• (2)的結束時間是Branch1.0.1開發的結束時間。結束時發佈1.0.1產品。此時作如下事情： 
  • 合併代碼以前，在1.0.1 Trunk上創建Tag，如：1.0.0_20180313。用來表示將1.0.1合併進來以前的代碼。
  • 將Branch1.0.1的代碼合併到Trunk1.0.1上。而且鎖定Trunk1.0.1代碼避免任何進一步的修改。
  • 從Trunk1.0.1上建立Branch 1.0.2，用於進行Branch 1.0.2的開發。

 

一些注意事項：

若是修復Bug，能夠在Trunk或者Branch上作，可是必定要使用SubVersion的合併功能，而不是在Trunk和Branch上分別改兩遍。若是改兩遍，形成的結果是在要將Branch合併到Trunk上出現衝突。

若是有些核心數據結構的變更，將它放在小版本升級後的第一個迭代進行。避免對用戶形成升級困難，或者用戶須要從新裝載全部數據。

合併代碼的時候須要很是當心，保證Branch上的代碼和合並之後Trunk的代碼同樣很是關鍵。若是不同會形成這種狀況：第一個從Branch上發佈的產品沒有問題；後來爲了修復一個Bug，從Trunk上發佈一個新版本後，出現了第一個發佈沒有出現的問題。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

環境版本如何扭轉

項目因具體狀況可能會出現多個測試環境進行維護的狀況，這裏以三套環境，N日爲週期爲例，該類狀況可參考如下流程進行版本發佈！

    角色：開發，測試，開發負責人、版本負責人

    環境：開發環境、測試環境、準生產環境

 

時間線	事務
T日	   9點版本負責人建立版本
	   9-16點，開發人員開發功能，修改BUG（BUG解決關聯禪道版本）
	   16-18點，開發負責人確認版本信息（開發功能，測試注意事項，SVN模塊最後version），提交版本負責人
	   版本負責統計項目各產品版本信息（開發功能，測試注意事項，SVN模塊最後version），驅動測試
T+N日	   T+1日9點，測試人員更新測試環境
	   T+1日至T+N日15點，測試-測試版本（依據ＢＵＧ，功能，測試注意事項進行測試），提交ＢＵＧ（ＢＵＧ關聯禪道版本）
	   T+N日15..30-17點，確認測試環境版本信息，提供項目經理（郵件描述版本更新內容及測試結果）
	   項目經理確認版本測試結果，驅動準生產環境進行更新
	   T+N日17點-18點。冒煙準生產
T+N+1日	測試準生產

 

開發版本：

 

測試版本：

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

產品研發過程管理的方法和工具

使用Redmine進行研發管理，Redmine不只能夠用來作軟件研發過程管理，並且能夠用來管理非軟件研發的項目。它給整個團隊一個總覽圖，同時記錄全部的細節。