摘要：隨着數字化、信息化、網絡化和智能化的普及和發展，企業對軟件服務的質量和上線速度要求越來越高。傳統研發模式難以滿足要求，企業的開發運維模式逐漸向敏捷和DevOps 轉型，敏捷和DevOps理念正被廣泛認可並加速落地實踐。
本文分享自華為雲社區《一文讀懂敏捷開發的發布策略》，作者：敏捷的小智。
隨着數字化、信息化、網絡化和智能化的普及和發展，企業對軟件服務的質量和上線速度要求越來越高。傳統研發模式難以滿足要求，企業的開發運維模式逐漸向敏捷和DevOps 轉型，敏捷和DevOps理念正被廣泛認可並加速落地實踐。本文主要闡述基於敏捷和DevOps的發布策略相關內容。
什么是發布策略
發布策略是不是發布方案、發布計划、發布方法？我們常聽到的藍綠發布、滾動發布、灰度發布是不是就是發布策略呢？下面我們就一起看一下。
發布
關於“發布”的含義，我們先看下它在整個軟件開發生命周期中的位置，如圖所示，發布是軟件開發全生命周期中的最后一環，直接面向最終用戶。
圖1 軟件研發流程
為了更好的理解交付，我們將各個環節逐一來看一下。
• 持續集成是開發人員提交了新代碼之后，就對整個應用進行構建，目的是讓正在開發的軟件始終處於可工作狀態；
• 持續交付是持續集成的延伸，將集成后的代碼部署到類生產環境，確保可以以可持續的方式快速向客戶發布新的更改；
• 持續部署是在持續交付的基礎上，將代碼盡早部署到生產環境，以確保可以小批次發布。持續部署是把部署到生產環境的過程自動化；
• 持續發布是把一個/組特性提供給（部分或全部）客戶的過程，在對用戶可見的這個過程稱為發布。持續發布是以持續部署為基礎。
• 持續測試是貫穿整個研發流程始終的，從持續集成到持續部署，都有自動化測試的存在。
更多相關的內容可以點擊持續交付與持續部署概念解讀 進行學習。
策略
根據百度百科，“策略”是為了實現某一個目標，首先預先根據可能出現的問題制定的若干對應的方案，並且，在實現目標的過程中，根據形勢的發展和變化來制定出新的方案，或者根據形勢的發展和變化來選擇相應的方案，最終實現目標。簡單來說，策略就是解決問題。詳細的說，策略就是為企業實現商業目標提供問題解決方案。
我們看幾個關鍵詞：目標、方案、形式的發展變化，即策略是動態變化的，一直以實現目標為核心。
發布策略
基於上面的解釋，在制定發布策略時，首先需要有目標。敏捷軟件開發理念的核心是敏捷宣言和敏捷原則，其中可以用來指導發布的有2條原則：
a) 我們最重要的目標，是通過及早和持續不斷地交付有價值的軟件使客戶滿意。
b) 經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向於采取較短的周期。
從大方向上來講，所有企業的發布都是為了創造價值，也就是對應到上面敏捷原則a）中的最重要目標——盡早交付可工作的軟件。“盡早交付”就是要縮短周期，減少時間，關於周期的長度，在敏捷原則b）中指出可以相隔幾星期或者一兩個月；“可工作”需要保證發布的質量，做好發布的風險控制。由此可見，發布策略的具體化目標應該是實現產品的高頻低風險的發布。
其次，發布策略不是在即將發布的時候才制定，應該是項目計划階段的一部分。由產品從研發到上線過程中的所有相關團隊負責人共同討論制定，內容是整個產品生命周期中的發布相關事宜，包括發布前、發布中和發布后三個階段。發布前最重要的是發布計划，發布過程中監控和日志管理、問題應對方案，發布后的維護方案，整個內容要形成一份文檔記錄下來。
最后，在整個生命周期中，隨着需求的變化，發布策略也會動態的隨着項目同時改變，文檔要做好同步進行更新和維護。
高頻低風險的發布
理解了發布策略之后，下面我們主要介紹實現高頻低風險發布目標的核心要素，發布分支和發布方法。
發布分支的選擇
使用合適的發布分支，可以減少執行發布所需的時間，是高頻發布的前提。團隊要根據產品的類型、業務的發布周期要求、企業的自動化程度和團隊的能力及特點來選擇不同的分支策略。發布分支主要有主干發布和分支發布兩種。
主干發布
主干發布就是用主干代碼進行軟件發布，所有新特性的開發，都提交到主干上，當需要發布的時候，直接把主干上的代碼部署到生產環境。這樣可以一直保持主干代碼處於隨時可發布的狀態。
基於主干發布，團隊可以選擇主干開發和分支開發兩種對應的模式。不論是那種開發模式，都要做到兩點：一是早提交，要將代碼盡早提交到主干，縮短開發分支的生存周期。因為分支周期越長，積累的代碼數量就越多，在提交到主干分支的時候產生沖突的機會就越大，這樣就會增加合並的時間。關於開發分支生存周期多短算是合適，業界說法不統一，在《持續交付2.0》中給出的意見是控制在3天以下，可以結合自己的業務情況做參考。實現短周期需要在最初需求拆分的時候做好規划，控制好需求的顆粒度；二是早同步，每個開發分支在工作過程中，要及時和主干代碼進行同步，至少每天1次，這樣可以減少最后合並過程中的代碼沖突問題。
分支發布
分支發布是專門從主干上拉出一個發布分支，用於對外發布。這樣可以在發布的同時，主干持續進行開發，不會受到版本發布的影響。新版本發布后出現缺陷，可以在發布分支修改后同步到主干，也可以在主干上修改后合並到發布分支。
使用分支發布的時候也要注意兩點：一個是分支的存在周期不要過長，如果在發布分支上修改了缺陷，要及時同步到主干分支；二是不要從發布分支創建新的分支，所有的分支都應該來源於主干分支，保證代碼源的唯一性。
綜上所述，我們看到不論是主干發布還是分支發布，如果想實現高頻低風險，重要的就是要做好三個控制：
一是控制分支數，越少越好，最好只有主干分支。
二是控制分支生存周期，越短越好。
三是控制發布周期，越短越好。軟件發布頻率越高，發布周期就越短。當達到了一定的發布頻率時，就不需要發布分支了，主干發布即可。
常用的發布方法
開篇提到的藍綠發布、滾動發布、灰度發布都是發布策略中常用的發布方法，可以降低發布風險，實現零停機發布，是發布策略中的核心內容。
藍綠發布
藍綠發布，是一種可以保證系統在不間斷提供服務的情況下上線的部署方式。“藍”和“綠”代表兩套獨立的環境，使用完全相同的主機集群，有兩種使用策略：
• 一種是一套環境在線提供服務，一套環境閑置，准備用於下個版本的發布。
• 另一種是將兩套環境都在線提供服務，可互為容災。此時藍綠兩組主機工作方式如下：
1、無新版本發布時，藍主機組和綠主機組同時對外提供服務；
2、當需要升級版本時，首先把藍主機組從負載列表中摘除，進行升級，綠主機組依然對外提供服務；
3、藍主機組升級完成，則將流量切換到綠主機組，同時將綠主機組從負載列表中刪除，進行升級；
4、當藍綠主機均完成升級，將綠主機組重新恢復至負載列表，兩組主機重新同時對外提供新版本的服務。
圖2 藍綠發布
藍綠發布的好處是可以實現零停機發布，可以實時升級和回退。不足是需要雙倍的主機資源，而且切換是全量的，如果新版本有問題，則對用戶體驗有很大的影響。
滾動發布
滾動發布，是在發布的過程中先將一台或者幾台主機停止服務，進行版本升級后重新提供服務。然后再選擇下一批升級的主機同樣操作，直到所有的主機都升級完成。
滾動發布的好處是用戶體驗影響小，體驗較平滑。不足是版本在緩慢替換，發布和回退都比較緩慢；滾動升級期間，新老版本共存，如果發現問題，難以定位到底是新版本還是老版本的問題；滾動升級期間的流量控制對資源的要求比較高。
灰度發布
灰度發布是讓一部分用戶繼續用版本A，一部分用戶開始用版本B，如果用戶對版本B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到版本B上面來。灰度發布是金絲雀發布的延伸，金絲雀發布是灰度發布的初始階段。對於需要划分多少階段，每個階段的用戶數量是多少，根據業務和產品具體情況進行制定。在下圖中的內部用戶可以看做是金絲雀用戶。
圖3 灰度發布
灰度發布的好處不需要進行停機，同時只有部分用戶獲取新版本，如果新版本出現問題，用戶體驗影響比較小，可以保證整體系統的穩定。不足是發布的時間會比較長；升級期間的流量控制對資源要求比較高。
其實，不論是哪種發布方法，降低發布風險的最佳方法就是真正地做發布演練，越頻繁的將應用程序發布到不同的測試環境越好。這樣就說明測試環境越可靠，從而在生產環境中發布時遇到問題的可能性就越小。
國內現狀
高頻低風險的發布已經成為了企業的主要趨勢，根據雲計算開源產業聯盟發布的2021年《中國DevOps 現狀調查報告》，國內企業部署頻率為1周—1個月的占比超六成，相比2020年增長近一成。
圖4部署頻率現狀分布
調查顯示，僅有16.21%的企業能夠每天多次在生產環境進行部署；此外，6.19%的企業平均1天到1周在生產環境部署一次；28.25%的企業平均1周到2周在生產環境部署一次；32.90%的企業平均2周到1個月在生產環境部署一次；部署頻率超過1個月的企業占9.33%。
參考附錄
1、Jez Humble. David Farley.持續交付：發布可靠軟件的系統方法北京：人民郵電出版社。
2、喬梁.持續交付2.0：業務引領的DevOps精要.北京：人民郵電出版社。
3、《中國DevOps 現狀調查報告（2021）》. 雲計算開源產業聯盟發布。