現在，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年的百姓網也使用這種發布火車模式，每個工作日早上七點鐘更新其網站。

雖然項目制發布方式短期內不會消失，但是，城際快線模式可以做為軟件交付團隊能力的一種指示器。

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

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