[轉載]版本發佈模式有幾種？

如今，IT媒體把DevOps炒的火熱，但仍是讓咱們來一塊兒研究一下最基本的東西吧。由於這些最基本的東西會從根本上影響你作事的方式。

 

今天先談談軟件版本發佈模式。

選擇版本發佈策略時，一般有如下三個維度能夠調整（時間、特性集和質量）。

 

依據三個調整項，能夠總結爲以下三種發佈模式：

 項目制發佈模式(Project Rlease Mode);

 傳統版本火車模式（Release Train Mode）

 城際快線模式 (IntercityExpress Mode)

 

---

 

項目制發佈模式是指在軟件某一個版本規劃中，預先肯定該版本所需包含的特性集合，當該集合內的全部特性所有開發完成（一般不包含那些還沒有開發完成的特性的相關代碼），而且達到相應的發佈質量標準後，才能發佈該版本。先後兩次發佈之間的時間間隔並無明確的規定，而是根據前一版本全部特性集合開發完成並達到發佈標準所需時間進行評估肯定的。

明顯的好處在於：能夠確切地知道每一個版本包括哪些具體功能，有利於商業套裝軟件的售賣模式（賣版本拷貝和license，收取軟件維護費用，當包含有新功能的版本發行後，再向客戶收取新版本的升級費用）。同時，這也符合人們的安全生產習慣，即：不可以把未完成的功能帶到即將發佈的版本中，由於這會增長缺陷風險。

其不足之處在於：一般項目整個交付週期較長，參與人員衆多。當在版本研發週期內，因某些緣由致使需求變動（如增長需求、修改原有需求實現方式、或者進行需求置換）時，須要從新肯定項目的交付時間，就會影響那些能夠定期交付的需求的使用時間。由於這些需求一般不得不等待全部需求實現完成後才能一塊兒發佈。

 

傳統發佈火車模式常見於大型套裝分發類軟件。大型傳統軟件企業一般有多條產品線，各產品線之間存在很是複雜的相互依賴關係。爲了可以使各產品線協同發佈，這些企業一般會爲每條產品線都制定好每一個版本的發佈週期，即：每一個版本都象一列火車，事先計劃好什麼時間發車。爲了可以準時發佈，要求全部參與到該版本開發的團隊必須對齊該版本的各個開發階段。這種嚴格的時間一致性要求是由於該產品線的時間變動會引發其它產品線的變動，而這些更改極可能影響共享的系統集成測試環境的分配。 在大多數狀況下，因爲計劃和集成依賴關係，發佈列車設置爲季度交付窗口，但一般不會超過10個月。

當公佈這種發佈火車時間表時，發佈管理團隊一般提早與負責各類產品系統開發的團隊（有時甚至提早幾個月），並將其結論公佈在企業版本表中，相似於下圖（LiberOffice的版本火車的時刻表 ）。

 

提早幾個月制定發佈火車的時間表，緣由純粹是讓各類業務和技術部門有足夠多的時間進行預計劃，以便作出依賴和影響的相關評估工做。

這種模式指望經過更長時間的預計劃，保障三個維度（時間、質量、特性）都能符合預期。

這種模式的好處在於：用戶能夠事先了解重要特性在各版本的分佈，以及對應版本的發佈時間，並可以提早體驗到最新產品版本所提供的新特性，而後再根據體驗結果，決定是否將其應用於本身的生產環境上。並且，既便決定要在本身的生產環境中使用這個版本，也能夠等到這個新版本成熟穩定以後再使用。

其不足之處在於：須要提早較長時間作時間計劃，並且制定發佈計劃的活動是一個很是正式和結構化的過程，而且須要一些格式化數據，以確保參加發佈火車的團隊可以對正式加入的可行性作出判斷。這些數據包括：

1. 發佈詳細信息（相對標識，名稱，部署日期，風險級別，發佈類型 - 企業，計劃或投資組合）

2. 整個生命週期中各個階段及預約日期，以下圖（LibreOffice5.4版本火車的時間表 ）所示。

3. 每一個階段要完成的活動和任務

4. 里程碑時間和質量要求

5. 負責管理髮布火車的主要負責人。

 

 

 

 

城際快線模式（Intercity Express Mode）是指在發佈策略三要素中選擇固定其中的時間和質量兩個維度，且時間週期相對較短（如一個星期，甚至一天），針對那些在發佈時間點前已達到固定質量標準的特性進行發佈。

它與傳統發佈火車模式的區別在於兩點：

（1）發佈週期間隔較短，一般在兩個星期內；

（2）負責特性開發的團隊能夠本身選擇搭乘哪列城際快線，而沒必要提早很長時間肯定下來。

這種模式常見於提供互聯網服務或SaaS服務的軟件公司。其好處在於減小了團隊及角色之間的協調成本。由於每一個人都事先知道每次發佈的具體時間點，全部工做任務均可以按這個時間點提早進行協調。並且，即便某個特性沒有及時遇上最近的一次版本發佈，他們也確切地知道這個特性是否能夠在下一次發佈時間點對外發布。

好比，Facebook Web主站的發佈週期是每一個工做日兩次發佈。

 

這種城際快線模式的優勢在於：

（1） 每一個人都很是清楚各個時間點；

（2） 每一個人都感受到特性進展；

（3） 速度不斷提高；

（4） 更加聚焦於生產質量。

固然，也有其不足之處：

（1） 未完成的代碼也會一同發佈出去；

（2） 每一個人都有緊迫感；

（3） 若是頻率變慢，須要更多作計劃的時間

那麼，這樣的發佈火車，間隔多長時間發出一趟合適呢？在不瞭解企業具體情況時，這是一個很是難回答的一個問題，但仍舊能夠給出一些建議，

即：在不影響用戶體驗、不增長成本且合規的前提下，讓發佈週期儘量縮短到令你感到有些緊張的節奏。好比原來每月發佈一個版本，如今能夠把兩個星期作爲一個目標。固然，這不可能輕鬆作到。

 

分支策略與版本發佈模式之間的關聯關係

分支策略與版本發佈之間有一種微妙的相關性，在時間週期較長的項目制發佈模式下，研發團隊採用的分支策略一般會傾向於主幹開發模式，而在使用城際快線模式的團隊中，也一般會傾向於採用主幹開發模式。而發佈週期在二者之間時，其分支策略一般會傾向於「多分支開發，主幹發佈」的模式（不管是特性分支也好，仍是團隊分支也好）。固然，這並非絕對的，其中會有很大的重疊部分，一般會受團隊成員人數和產品架構影響。

項目制發佈模式不會消失。畢竟每一個新產品在完成第一個基本的MVP前，都須要這樣一個首次啓動過程。目前仍舊有不少傳統IT企業採用項目制發佈模式。

然而，城際快線模式愈來愈受到歡迎。已經有愈來愈多的企業 開始使用這種城際快線模式。即便在那些目前的版本發佈週期較長的企業中，也經常在項目制發佈模式中套用城際快線模式，即：在項目週期內加入固定時間的迭代，並要求在每一個迭代結束時都能獲得可交付狀態的產品。這裏的可交付狀態是指軟件能夠正常運行，且已完成的軟件特性達到發佈質量標準，而非可商業化發佈。

通常來講，當發佈週期短到必定程度後，主幹開發模式更加具備優點，由於分支開發模式的合併成本會成爲城際快線發佈模式的障礙。

若是發佈週期等於或短於兩個星期，建議軟件團隊絕不猶豫地改進工做方式，轉向「主幹開發模式」。

 

不少互聯網公司選擇城際快線模式。如2010年以前，Facebook主站就開始使用這種城際快線模式，2012年更是達到每一個工做日定時發佈兩次。其移動端的發版節奏也從最初的項目制發佈模式改成城際快線模式。而google的Chrome PC版本也是選擇了城際快線模式 ，其Beta版本每週發佈一次，而Stable版本每個月發佈一次。在國內公司中，2011年的百姓網也使用這種發佈火車模式，每一個工做日早上七點鐘更新其網站。

 

雖然項目制發佈方式短時間內不會消失，可是，城際快線模式能夠作爲軟件交付團隊能力的一種指示器。

 

標註： 《版本發佈模式有幾種？》