低風險發(fā)布,再讀《持續(xù)交付2.0(增訂版)》

兩年前看了喬梁編寫的《持續(xù)交付2.0》，收獲頗多，還寫了一篇讀書筆記，今年 2 月，該書出了增訂本，增加了一個章節(jié)的內(nèi)容，其他的一些章節(jié)內(nèi)容也有局部的優(yōu)化。

花了一個多星期，翻閱了這本增定本，就像在之前讀書筆記中說的，好書是常讀常新的，每次都會帶來新的收獲和思考，取決于你當下的認知和期望能解決的問題。

新增的第 17 章主要在講研發(fā)組織的效能提升，從軟件的復(fù)雜度，談到了產(chǎn)品研發(fā)的勝任力模型到最后的組織健康度，在一個比較抽象的層面給我們打開了思路，因為篇幅的原因，沒有展開講。

相比新增的章節(jié)，我重新看的過程中發(fā)現(xiàn)低風險發(fā)布是我最感興趣的，我們現(xiàn)在的產(chǎn)品正在進行 SaaS 化改造，上線后就會面臨著持續(xù)發(fā)布的問題，這里面的內(nèi)容正好用得上。

下面說幾個我們遇到的問題以及按照書中的思路應(yīng)該怎么去解決：

1、發(fā)布上線，怎樣保證穩(wěn)定性？

通常我們發(fā)布上線，就是停機發(fā)布，發(fā)布后，所有的人看到的都是最新的版本。這樣其實風險是比較高的，風險有兩個方面，一是生產(chǎn)環(huán)境和測試環(huán)境總會有些差異，有時在測試環(huán)境沒有問題到生產(chǎn)會出現(xiàn)問題；二是程序上有缺陷會影響到所有的用戶。

下面有幾種低風險的發(fā)布方式：

藍綠部署：

假設(shè)現(xiàn)在有一個生產(chǎn)環(huán)境 A，再準備一套和這個生產(chǎn)環(huán)境完全一致的環(huán)境 B，其中 A 對外提供服務(wù)，B 作為預(yù)發(fā)布環(huán)境。

發(fā)布時，發(fā)布到 B 環(huán)境，可以在這個環(huán)境上做一些測試驗證，沒有問題后，將 B 對外提供服務(wù)，A 作為下一次的預(yù)發(fā)布環(huán)境，如此循環(huán)。

這種方式有個問題就是需要考慮到數(shù)據(jù)庫，如果兩個環(huán)境使用一個數(shù)據(jù)庫，就需要處理兩個不同版本的兼容性問題；如果每個環(huán)境都有自己的數(shù)據(jù)庫，那么在兩個環(huán)境進行切換時，可能會存在數(shù)據(jù)不一致的問題。

灰度發(fā)布：

一個新功能上線，讓一部分人先使用，然后陸續(xù)開放給所有用戶。如有問題，只會影響到一小部分用戶。

很多互聯(lián)網(wǎng)公司采用這種方式來驗證一個新的功能是否受歡迎。微信發(fā)布新功能，很多時候也是采用灰度的方式。

在部署時，可以先只更新其中的某些節(jié)點，那么負載到這些節(jié)點的用戶看到的就是新的內(nèi)容，其他節(jié)點的還是之前的內(nèi)容，至于誰能看到這些新的內(nèi)容，在網(wǎng)關(guān)層可以根據(jù) IP、區(qū)域、特定用戶等來進行負載，具體看業(yè)務(wù)場景了。

滾動發(fā)布：

一個集群中有很多個節(jié)點，選擇其中一個停止服務(wù)，進行更新，更新完后將其投入使用，依次將所有的節(jié)點更新完。

我們現(xiàn)在有一個客戶每次升級就是采用這種方式，對用戶來說幾乎是無感知的，因為一個節(jié)點在進行升級的時候，其他的節(jié)點依然能夠提供服務(wù)。

但有一個點需要注意，就是如果版本更新較大涉及到了數(shù)據(jù)庫結(jié)構(gòu)的改動，需要做兼容性處理。

2、產(chǎn)品進行大規(guī)模的重構(gòu)時，常規(guī)功能怎樣同時進行？

去年我們就經(jīng)歷過一次比較大的重構(gòu)，主要做了很多的代碼結(jié)構(gòu)的調(diào)整，提升程序的性能，而在這個期間，幾乎沒有做常規(guī)功能的迭代，我們的做法就是以當前發(fā)布分支拉取一個優(yōu)化分支進行代碼修改，發(fā)布分支上只做些 Bug 修復(fù)，修復(fù)完后就及時合并到優(yōu)化分支，最后優(yōu)化完成，再合并到發(fā)布分支。

而我們想要的是一邊做常規(guī)功能，一邊進行優(yōu)化。

首先分析進行重構(gòu)的部分是不是能夠進行拆解，如果能夠拆分成一些小的獨立的部分，就可以安排在迭代內(nèi)完成并和常規(guī)功能一起發(fā)布上線。

很多時候，重構(gòu)優(yōu)化涉及的模塊非常多，這時就可以引入中間層，加上開關(guān)控制，新的邏輯和老的邏輯同時存在，逐步替換，等到所有的都替換完后，再將老的邏輯刪除。

唯一不足的就是重構(gòu)的周期會比較長。

3、在一個迭代周期內(nèi)，前后端的任務(wù)總是不能吻合地很好，應(yīng)該怎么辦？

這里說的吻合是指在一個迭代中前端和后端的任務(wù)量相當，同時結(jié)束工作，同時開始下一迭代。以我們這半年實踐敏捷開發(fā)發(fā)現(xiàn)，這種理想狀況很難。

我們現(xiàn)在的模式是三周迭代，以目前的能力無法做到每個開發(fā)人員的任務(wù)安排到最后一天，因為最后幾天測試人員要進行整體回歸測試。這就存在一個銜接的問題，開發(fā)人員在當前迭代的任務(wù)結(jié)束了，但迭代周期沒有結(jié)束，那么開發(fā)人員應(yīng)該做什么？

關(guān)于這個問題，我跟領(lǐng)導(dǎo)溝通過很多次，最近也咨詢了一家大公司的產(chǎn)品團隊負責人，再加上本書中的講解，我大致總結(jié)了下：

• 在敏捷團隊中，所有人都是為了一個迭代目標而努力，去沖刺；
• 在一個迭代中，開發(fā)人員的開發(fā)任務(wù)完成了，可以參與測試、進行后續(xù)任務(wù)的技術(shù)驗證、或者一些非功能性需求的實現(xiàn)（代碼優(yōu)化、擴展性、可讀性、性能等）；
• 一個迭代中的任務(wù)保證前端都是可以測試和交付，但后端人員如果有空閑，可以多安排后端任務(wù)，發(fā)布后，因為沒有操作入口，也不會產(chǎn)生影響；
• 盡可能在一個迭代周期內(nèi)完成能發(fā)布的功能，如果有些不能發(fā)布，通過開關(guān)來進行控制。

這是第二次讀這本書，但我相信不會是最后一次。