編者按：本文源自阿里云云效團隊出品的《阿里巴巴DevOps實踐指南》，掃描上方二維碼或前往：https://developer.aliyun.com/topic/devops，下載完整版電子書，了解阿里十年DevOps實踐經驗，
每個軟體都無法離開其依賴的運行環境，從代碼的撰寫、除錯、測驗、上線、運維，每個步驟都離不開對應環境的支持，對于測驗環境的爭用、環境各階段需要滿足不同應用場景、軟體質量的守護、成本與效率優化等諸多訴求，是環境治理和基于環境的變更交付流程規范化的原始需求，
軟體行業對效率的要求是非常高的，如何能在現有條件下，提高開發測驗的效率是一個很有意義的問題，而在這個問題中，環境，又是一個避不開的話題，如果每個開發都能在自己專屬的環境里進行開發除錯，不受外部人和物的因素干擾，自然會比較高效，然而，在微服務大行其道的今天，在同個軟體模塊多人多專案并行開發的情況下，為每個開發都分配一整套包含所有服務的環境，從硬體成本和維護成本上說，都不是一個明智的選擇，有效的對環境進行隔離和編排，可以在保證開發效率的同時，優化硬體成本和維護成本，
軟體開發通常需要經歷多階段的反復測驗驗證，是從無到有，從簡到豐，從不穩定到穩定的一個程序，正是由于這樣的特點，不同階段中對應的環境特性也會不一樣，例如最開始的開發環境，用途就是個人測驗；線下集成環境，用于線下的集成測驗；預發環境，用于上線前的回歸測驗及驗收；正式環境，用于真正給用戶提供服務等等，
用流程將不同的環境串聯，能將原來松散凌亂的開發流程變得規范化，再加上合適的測驗、驗證及準入卡點等手段，實作滿足準入條件（如質量標準等）才能交付下一階段環境部署，通過系統流程化的方式引導開發者來完成安全、高效、可信的變更交付，避免交付程序無規則導致的混亂及安全隱患，同時可以讓整個研發流程做到可視化、可追溯、可度量，
總而言之，基于應用環境的變更交付，需要具備兩大能力：
- 單應用多開發者并行開發互不干擾的測驗環境隔離能力
- 基于環境的變更交付程序規范化的流程管理能力
解決方案
在微服務架構的大背景下，服務的數量大大增加，使得原本大應用內部模塊的復雜性轉化為了多個小應用服務之間的呼叫復雜性，在實際業務場景下，一個整體業務通常會由多個小的應用服務組成，因此，在開發整體業務的程序中，通常涉及到上下游一系列的微服務應用的修改，并且在多個不同業務的開發程序中，會導致同個微服務應用有不同的服務版本，大大增加了微服務之間的聯調復雜性，給開發測驗程序帶來了除開發業務本身外的額外成本，
如何減輕聯調的系統成本，讓研發專注于自身的業務，是環境治理亟待解決的問題，為了更好的支持研發作業，通過將環境進行專職分類、編排隔離域、交付程序規范化，幫助研發更高效的交付軟體產品，阿里沉淀出了一系列在測驗環境治理方面的最佳實踐，這些實踐包括：
代碼變更在環境上的遞進機制
環境分為兩大類：線上環境和線下環境，線上環境是那些操作和資料會真正影響到實際用戶服務的環境，例如預發、beta、灰度、生產等，線下環境是主要提供給研發進行開發測驗的，目前按使用方式主要分為專案環境、集成環境、基礎環境三大類，本篇著重介紹線下環境，其中：
- 專案環境：單個應用的單個開發中特性獨占的環境，不受其他開發中特性的影響，也不會影響到其他環境的使用，用戶可以在這個環境上進行任意的占用除錯或破壞性測驗，
- 集成環境：一個應用的多個開發中特性共享的環境，這個環境主要用來驗證多開發中特性在集成以后是否會在業務上產生新的問題或是引入新的沖突，
- 基礎環境：提供上述專案環境和集成環境的服務依賴，通過在生產環境部署后立即部署基礎環境，來保證基礎環境提供的服務都是最新的生產環境運行版本，從而保障上述專案環境和集成環境能夠穩定的進行開發測驗，
流程上，從拉取特性分支開始，自動分配專案環境，在特性分支線下測驗基本完成后，將專案環境轉為集成環境，同其他特性分支一起測驗，在集成環境測驗通過后，部署至線上環境，最后在特性分支合并至主干后，用最新的生產版本更新基礎環境，
編排隔離域
隨著業務的不斷增長，當前的測驗環境需要支持數萬開發工程師的同時使用，對于某些核心業務，有數百個開發中的業務特性同時進行開發測驗，而大部分的業務特性都涉及到多個不同微服務的修改，如何保證多個并行業務之間能相互獨立，不會相互影響？解決方案是隔離，將同個業務特性的多個不同微服務的環境圈定為一個隔離域，保證相關呼叫在隔離域內進行，這樣就能隔絕其他的業務特性提供的服務對這個業務特性開發測驗的干擾，在用戶看起來，這個業務特性仿佛擁有了一套完整的環境，
然而，在微服務大行其道的今天，一個業務特性的運行通常依賴著許許多多其他的服務，如果每個隔離域內都將這些服務全部部署作為支撐，是一件成本非常高的事情，我們的解決方案是共享，從路由維度出發，所有隔離域共享基礎環境，而保留隔離域自身的專案和集成環境，來達到盡可能的復用公共服務的目的，大量減少了資源成本和環境維護成本，
如圖，專案環境 1 的用戶和專案環境 2 用戶分別拉起隔離域進行聯調，相互之間流量隔離互不干擾，隔離域不存在的服務都復用基礎環境進行服務兜底，待特性開發分支經過集成、預發驗證并發布生產環境后，會自動更新基礎環境的基線版本，所以基礎環境會持續保持跟生產環境相同的穩定版本，以提供穩定的支撐服務，
基礎環境建設
微服務架構場景下從端發起的一次呼叫，會涉及到呼叫鏈路上多個應用提供的服務，但在實際的開發聯調中，一條鏈路上只有少部分的應用需要變更，如果面向開發者需要拉起整個鏈路進行開發聯調，那么會帶來低效和成本的問題，所以其中非變更應用可以采用基礎環境作為服務支撐，如何保證基礎環境的穩定可用就是隔離環境建設的重點，為了保證基礎環境的可用性，主要做了三方面的作業：
- 降低接入基礎環境成本：創建環境通常是一個比較讓開發頭疼的作業，通常涉及到上下游一系列配置作業，例如修改發布流程、增加 Dockerfile、下發環境隔離檔案、準備測驗域名、申請相應資源等，為了實作基礎環境解決方案的落地，需要實作批量的基礎環境搭建，程序中需要具備用戶一鍵搭建基礎環境及相應配套的能力，降低基礎環境的接入成本，
- 代碼層面保證服務穩定：基礎環境只部署最新的主干代碼版本，而且通過系統流程保證每當線上部署完成，發布特性分支代碼合入主干分支后，將基線版本自動部署到基礎環境，用戶無法直接部署開發中的特性到基礎環境上，從代碼版本管理層面來保證基礎環境服務的穩定性，
- 可持續流量與自愈、監控保障：為了保證基礎環境穩定服務的可持續性，基礎環境需要穩定的全鏈路測驗流量及監控，實時監測基礎環境的可用性，在發現基礎環境服務不可用時，首先通過無人值守的系統手段自愈，如果還是不可用，通過自動工單機制通知并跟蹤基礎環境的恢復行程，
基于環境的交付流程
從拉取變更代碼特性分支，到最終特性分支交付正式發布大致分為幾個階段：創建變更特性分支、變更特性分支功能開發、分支功能除錯及自動化驗證、多分支集成驗證、準入卡點、提交預發驗證、正式發布上線（如下圖所示），
其中預發準入卡點是為了保障達到一定質量要求的代碼才能進入預發驗收，把低質量的代碼攔在測驗環境持續驗證，而自動部署環境則是為了減輕準入卡點給開發者帶來的負擔，通過自動化手段來對特性分支代碼持續驗證，收集并沉淀質量資料，為準入卡點提供判斷依據，
自動部署環境
當用戶通過系統創建特性分支時，會自動為用戶的新創建分支申請一個專案環境，該專案環境的配置與基礎環境相同，并自動進行資源分配、部署操作，同時，這個專案環境的呼叫和訊息同其他環境相互隔離，它的服務并不會影響到其他環境的呼叫，
每當用戶所創建的特性分支提交了新的代碼，都會自動觸發系統去進行一次部署及自動化測驗驗證，通過持續的變更提交+反饋，縮短特性分支變更缺陷的反饋周期，幫助開發盡早修復代碼缺陷，
分支版本準入卡點
在研發交付的程序中，通過開放配置流程的能力，可以讓業務方靈活的根據業務需要，配置所需的流程步驟，通過流水線步驟的自動推進，完成從測驗到上線的整個交付程序，流水線是由一個個組件組成的，每個流水線都可以串聯一到多個組件，在阿里巴巴的最佳實踐中，在某些環境的部署組件后配置代碼質量管控的組件，可以讓環境在部署后，馬上自動觸發測驗組件，來驗證最新的部署版本是否符合質量要求，從而倒推出最新變化的代碼是否符合質量要求，
使用中，為了保證線上環境的安全和穩定，在提交預發環境集成部署之前，會判斷所要發布的分支的最新版本是否都通過了準入質量要求，沒有達到質量要求的代碼變更會被攔在測驗環境繼續修復驗證以保障生產環境的安全，
環境與測驗技術的結合
自動化測驗一直作為有效的驗證手段被廣泛使用，然而，在實際使用程序中，用戶對于自動化測驗用例的詬病并不少，例如：
- 測驗用例本身有問題，而不是被測驗的代碼有問題，導致花費了大量時間排查后，在確定本身代碼沒有問題，才能反查測驗用例的正確性，排查成本較高，
- 破窗效應明顯，一個開發的懶惰導致測驗用例失敗，其他開發人員并沒有足夠的動力將測驗用例修復，同時由于他人的原因導致測驗用例無法通過，也就降低了自身對測驗用例的要求，幾次下來就會導致測驗用例的情況越來越糟糕，
- 責任排查難，大多數測驗用例只會告訴你這次失敗還是成功，但是無法關聯比較多次測驗用例之間的代碼變動情況，當測驗用例失敗時，用戶并不知道上次測驗用例成功到這次測驗用例失敗之間，變動的是哪些代碼，帶來高昂的定位成本，
針對這樣的情況，我們需要從更高緯度的視角去關聯代碼版本與測驗用例，主要分為兩點：
- 常態化代碼主干測驗用例回歸：在每天夜里系統自動根據主干代碼創建應用環境并隔離、部署，然后跑對應的測驗用例，由于是主干代碼，因此受到的代碼干擾較小，如果通過，表示該測驗用例有效釋放環境，如果不通過，則保留現場，并自動創建發送訊息到用例負責人，通過常態化的跑測驗，能對比上一天的結果來快速定位問題，并能保證“測驗用例本身有問題”時能盡快得到解決，
- 測驗用例對比迅速定位代碼：系統將每次跑測驗用例的各個分支代碼版本、集成分支代碼版本都保存下來并進行關聯，當測驗用例失敗時，能直接定位到上次這些分支測驗通過時候的代碼版本，將提交記錄直接展示給用戶，幫助用戶定位測驗用例失敗的原因，
上述程序需要結合環境的一鍵拉起和流量隔離能力，通過這兩點措施，可以讓測驗用例失敗時做到結果可對比、原因可回溯，防止測驗用例失敗的破窗效應出現，
總結
應用環境解決方案并不僅僅是將應用的開發環境、基礎環境搭建起來即可，還涉及到環境的穩定性如何保證，基于環境如何規范變更的流程，基于環境如何提升開發效率等等，環境治理需要站在更高的角度，綜合看待上述問題，否則就會陷入環境問題年年治理、年年被吐槽的怪圈，
【關于云效】
云效，云原生時代一站式BizDevOps平臺，支持公共云、專有云和混合云多種部署形態，通過云原生新技術和研發新模式，助力創新創業和數字化轉型企業快速實作研發敏捷和組織敏捷，打造“雙敏”組織，實作 10 倍效能提升，
立即體驗
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/420427.html
標籤：其他
上一篇：如何高效完成ECS多環境部署？