帶你瞭解敏捷和DevOps的釋出策略
摘要：隨著數字化、資訊化、網路化和智慧化的普及和發展，企業對軟體服務的質量和上線速度要求越來越高。傳統研發模式難以滿足要求，企業的開發運維模式逐漸向敏捷和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）》. 雲端計算開源產業聯盟釋出。