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