起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識火車模型發布模式：敏捷和穩定
編輯導語：我們都知道，火車的班次是經過了長時間的計劃和排列才得出的最終班次結果，火車的時間非常的穩定，一般不會延誤或者遲到，他的信息網也非常密集；本文作者分析了火車模型發布模式的特點，我們一起來看一下。
在說火車模型之前我們先來說說現有的版本發布模式。
參考喬梁的持續交付2.0中，從特性、時間、質量三個角度總結的三種發布模式：
- 項目制發布模式（Project Rlease Mode）
- 傳統版本火車模式（Release Train Mode）
- 城際快線模式（IntercityExpress Mode）
一、項目制發布模式
項目制發布模式是指在軟件某一個版本規劃中，預先確定這個版本所需包含的特性集合；當版本的特性集合達到發布質量標準后，才能發布該版本，版本之間的時間間隔不確定，而是根據前一版本所有特性集合開發完成并達到發布標準所需時間進行評估確定的。
明顯的好處在于：可以確切地知道每個版本包括哪些具體功能，有利于商業套裝軟件的售賣模式符。
其不足之處在于：通常項目整個交付周期較長，參與人員眾多，需求的變更極易影響版本的交付時間。
二、火車模型發布模式
《啟示錄：打造用戶喜愛的產品》這邊說第一張就講到了許多成熟的互聯網公司都在使用火車模型發布模式。
Firefox目前正在采用的發布過程其實就是火車模型發布模式，使用一個新特性從實現并且進入mozilla-central分支到發布到用戶手里只需要12-18周，并不向IE瀏覽器的更新以用一樣要幾年的時間。
如此的快速發布過程給整個項目帶來了更好的敏捷性和更強的穩定性，在每個發布周期的測試和穩定階段可以覆蓋更多的用戶來幫助FireFox的開發人員更早的發現和解決問題，保持在每次發布質量上的信心。
下面就要介紹下Firefox的發布流程，每個獨立的發布火車（新的發布過程采用火車模型，固定的“發車”時間，特性的發布取決于該特性是否趕上最近的火車發車時間）包括6周的開發時間加上12周的穩定時間：
新的開發成果不會直接發布到Aurora和Beta分支上，這些分支需要被開發人員和社區測試人員共同測試完方可；如果發現開發中存在程序問題或者BUG，就需要先解決問題。
如上圖所示，您能夠看出發布周期基本上是穩定的18個星期。
Aurora和Beta分支基本上完全關注于穩定性和測試，同時，很多的工程師也在同步開始新的開發工作；所以，如果看更大的一張圖表的話，下面是真正進行的過程：
在Aurora和Beta分支上經歷的12周時間里，Mozilla開發社區并沒有在閑著，他們會繼續為后面的發布開發新的特性和bug fix。
每六個星期，他們的工作會被選擇性的合并到Aurora分支，繼而合并到Beta分支上；觀察上面的圖表，您會發現很重要的一點就是——每六個星期就會有一個新版本。
提前幾個月制定發布火車的時間表，原因純粹是讓各種業務和技術部門有足夠多的時間進行預計劃，以便做出依賴和影響的相關評估工作。
這種模式期望通過更長時間的預計劃，保障三個維度（時間、質量、特性）都能符合預期。
這種模式的好處在于：用戶可以事先了解重要特性在各版本的分布，以及對應版本的發布時間，并能夠提前體驗到最新產品版本所提供的新特性；然后再根據體驗結果，決定是否將其應用于自己的生產環境上；而且，既便決定要在自己的生產環境中使用這個版本，也可以等到這個新版本成熟穩定之后再使用。
其不足之處在于：需要提前較長時間做時間計劃，而且制定發布計劃的活動是一個非常正式和結構化的過程；并且需要一些格式化數據，以確保參加發布火車的團隊能夠對正式加入的可行性做出判斷。
這些數據包括：
- 發布詳細信息（相對標識、名稱、部署日期、風險級別、發布類型——企業、計劃或投資組合）；
- 整個生命周期中各個階段及預定日期，如下圖（LibreOffice5.4版本火車的時間表 ）所示；
- 每個階段要完成的活動和任務；
- 里程碑時間和質量要求；
- 負責管理發布火車的主要負責人。
三、城際快線模式（Intercity Express Mode）
城際快線模式（Intercity Express Mode）是指在發布策略三要素中選擇固定其中的時間和質量兩個維度，且時間周期相對較短（如一個星期，甚至一天），針對那些在發布時間點前已達到固定質量標準的特性進行發布。
它與傳統發布火車模式的區別在于兩點：
- 發布周期間隔較短，通常在兩個星期內；
- 負責特性開發的團隊可以自己選擇搭乘哪列城際快線，而不必提前很長時間確定下來。
這種模式常見于提供互聯網服務或SaaS服務的軟件公司，其好處在于減少了團隊及角色之間的協調成本——因為每個人都事先知道每次發布的具體時間點，所有工作任務都可以按這個時間點提前進行協調；而且，即使某個特性沒有及時趕上最近的一次版本發布，他們也確切地知道這個特性是否可以在下一次發布時間點對外發布。
比如，Facebook Web主站的發布周期是每個工作日兩次發布。
這種城際快線模式的優點在于：
- 每個人都非常清楚各個時間點；
- 每個人都感覺到特性進展；
- 速度不斷提升；
- 更加聚焦于生產質量。
當然，也有其不足之處：
- 未完成的代碼也會一同發布出去；
- 每個人都有緊迫感；
- 如果頻率變慢，需要更多做計劃的時間。
那么，這樣的發布火車，間隔多長時間發出一趟合適呢？
在不了解企業具體狀況時，這是一個非常難回答的一個問題，但仍舊可以給出一些建議，即：在不影響用戶體驗、不增加成本且合規的前提下，讓發布周期盡可能縮短到令你感到有些緊張的節奏；比如原來每個月發布一個版本，現在可以把兩個星期做為一個目標（當然，這不可能輕松做到）。
四、分支策略與版本發布模式之間的關聯關系
分支策略與版本發布之間有一種微妙的相關性，在時間周期較長的項目制發布模式下，研發團隊采用的分支策略通常會傾向于主干開發模式；而在使用城際快線模式的團隊中，也通常會傾向于采用主干開發模式。
而發布周期在兩者之間時，其分支策略通常會傾向于“多分支開發，主干發布”的模式（無論是特性分支也好，還是團隊分支也好）；當然，這并不是絕對的，其中會有很大的重疊部分，通常會受團隊成員人數和產品架構影響。
項目制發布模式不會消失。畢竟每個新產品在完成第一個基本的MVP前，都需要這樣一個首次啟動過程，目前仍舊有很多傳統IT企業采用項目制發布模式。
然而，城際快線模式越來越受到歡迎，已經有越來越多的企業 開始使用這種城際快線模式。
即使在那些目前的版本發布周期較長的企業中，也常常在項目制發布模式中套用城際快線模式，即：在項目周期內加入固定時間的迭代，并要求在每個迭代結束時都能得到可交付狀態的產品——這里的可交付狀態是指軟件可以正常運行，且已完成的軟件特性達到發布質量標準，而非可商業化發布。
一般來說，當發布周期短到一定程度后，主干開發模式更加具有優勢，因為分支開發模式的合并成本會成為城際快線發布模式的障礙。
如果發布周期等于或短于兩個星期，建議軟件團隊毫不猶豫地改進工作方式，轉向“主干開發模式”。
很多互聯網公司選擇城際快線模式，如2010年之前，Facebook主站就開始使用這種城際快線模式；2012年更是達到每個工作日定時發布兩次，其移動端的發版節奏也從最初的項目制發布模式改為城際快線模式。
而google的Chrome PC版本也是選擇了城際快線模式 ，其Beta版本每周發布一次，而Stable版本每月發布一次。
在國內公司中，2011年的百姓網也使用這種發布火車模式，每個工作日早上七點鐘更新其網站。
雖然項目制發布方式短期內不會消失，但是，城際快線模式可以做為軟件交付團隊能力的一種指示器。
參考文章：
喬梁 ：持續交付2.0
標點符：軟件開發中的火車模型發布模式
本文由 @非魚 翻譯發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
