“看，車來了！不過貌似我們趕不上這趟車了吧？”
“啊！那快點跑，錯過這趟就得再等半個小時！”
……
好無奈，可是真的趕不上也沒有辦法，這個場景很多人都經歷過。
“這個release又是一定包就開始上hotfix，四天跟了四個，我根本沒時間做迴歸測試！” QA小靜同學抱怨道。
“每次都是定包後就開始無休止的上hotfix，我們們還不如改成每週釋出一次！”Dev大鵬同學也被hotfix折磨苦了。
這是發生在藍鯨專案中一次真實而平常的對話，跟前面趕公交車的場景有什麼關係呢？
發車間隔與釋出週期
發車間隔的不同帶給乘客的感受會完全不同。
有些公交車很少，每半個小時一趟，有時候眼看著一輛車來了又走了，沒趕上會無比懊惱，下一趟還得等上半個小時，實在著急的可能會考慮叫一輛快車趕緊走。
而有些公交車發車間隔非常短，幾分鐘一趟，就算錯過一趟也無需等待太久，只要不是著急去救火，乘客一般不會太在乎。
專案的不同釋出週期帶給客戶的感受也是類似的。
藍鯨專案的釋出週期跟第一種公交車發車間隔非常類似，是四周釋出一次。如果功能沒能在這次上線，或者有導致功能無法正常工作的缺陷，得再等一個月才能再次上線。一個月，那是多少白花花的銀子啊！對於那些特別重要的功能，客戶著急就會要求上hotfix，於是就出現了前面小靜和大鵬的對話場景。
Hotfix是否真的能解決軟體交付過程中的問題呢？其實不然。
Hotfix的引入帶來很多額外的工作，影響新功能的按時交付，會打亂交付節奏，有形成惡性迴圈的趨勢。既然這樣，大家一定希望能把問題解決，而且通過公交車的例子很容易想到前面大鵬說的那個方案。
如果釋出週期縮短，比如說縮短為一週甚至更短，這次沒上的功能也不用那麼著急的通過hotfix來上線，就能解決問題。那麼藍鯨專案為什麼不一週釋出一次呢？
如何才能縮短髮布週期？
1. 合適的迭代計劃和合理的需求切分
半個小時一趟的公交車，就算車子足夠大、能夠承載半個小時到達的乘客數，也會導致乘客等待時間過長，造成很多不便。要解決這種情況，可以把大型公交車換成多輛小型車，增加發車次數，縮短髮車間隔。發車間隔縮短到多少，車子換成多大都是需要仔細分析和考慮的問題。
對映到藍鯨專案，要縮短髮布週期，就得有相應的小規模需求正好能夠乘坐小發布週期那樣的小車，因此要做好釋出計劃和需求切分。
這樣對需求源的要求很高，需要客戶那頭的緊密配合。要想縮短髮布週期，首先必須得有足夠的、粒度合適的功能需求，能夠正好安排到較短的釋出週期上線。如果需求範圍不能提前確定好，就沒法提前做好短週期釋出計劃，不可能把釋出週期縮短。
2. 強大的開發能力
在把乘客的需求分析清楚之後，縮短髮車間隔非常關鍵的一點就是要有足夠的安全的車和靠譜的司機。如果這一點滿足不了，其他都免談。
對應到藍鯨專案，安全的車子和靠譜的司機組成了擁有強大開發能力的團隊，包括架構支撐和人員技能。
車子就是對持續交付友好的技術架構，需要減少模組間的依賴，比如採用微服務。藍鯨專案是一個七年之久的老專案，很多陳年依賴已經形成，要拆分不是一時半會的事情，團隊正在朝著這個方向努力。
司機就是我們的開發團隊，除了要有必要的開發技能外，要做到靠譜就得透徹理解持續交付的精髓，需要團隊中人人都有質量意識，人人都有釋出週期的緊迫感，並且能夠做到高效合作，從需求劃分、程式碼質量、測試保障等做好各個環節的工作，做好缺陷的預防和監控，不讓嚴重缺陷流入後面階段。
藍鯨專案由於新人較多、人員流動大等原因，質量意識和緊迫感都有待提高。不過，在各位QA的影響下，這些問題都在改善，新人的技能也在不斷的學習和實踐中得到提高，但仍然不能放鬆警惕，需要時刻保持向前的精神面貌。
3. 充分必要的測試支撐
有了足夠的安全的車和足夠靠譜的司機，還得保證路況夠好，這樣才能做到不管到達哪個站，間隔都是相同的。
要想藍鯨專案的持續交付能夠順利前行、一路暢通，需要嚴格做好質量內建工作，各層都有充分必要的自動化測試保護，減少新功能開發過程中對老功能的破壞；同時持續整合流水線也要健全，不能耽誤程式碼提交和出包，以防影響開發和測試的進度。
藍鯨專案開發年限已久，複雜度很高，在持續交付的路上行走的有些坎坷。目前團隊正在這些方面努力採取改進措施，取得了不少進展，但確實還有不少提高的空間。
前景堪憂？
過去七年，藍鯨的持續交付之路有些坎坷，但不應因此而失去信心。
通過跟公交系統進行對比，我們可以看到藍鯨專案要縮短髮布週期、杜絕hotfix，需要從需求切分、迭代規劃、技術架構、團隊能力建設和測試策略調整等多方面進行優化，才能保證持續、快速的釋出節奏，這是一個系統的問題。
七年之癢已經平安度過，藍鯨團隊正在採取相應的改進措施，一旦做好了上述各方面的優化，在下一個七年，一週釋出一次或者更短的釋出週期都將不是夢！