背景：
業績流行的「測試泳道設計」目前在自如網中經由基礎架構中心自研的釋出系統「Omega」落地了，名為「特性環境」，但在推行業務線使用過程中實際效果并不理想。為深層次解決此問題，我們将進行調研與實踐。
01
問題分析
2022年8月底，梳理現狀。共分為三個問題部分：
1、穩定環境初始化難；
2、特性環境易用性差；
3、特性環境可靠性低。
1.1、穩定環境初始化難
1.1.1 骨幹鍊路配套缺乏
目前應用部署穩定環境依賴的上遊應用可能不存在穩定環境。
1.1.2 原有環境并存沖突
目前穩定環境與QA環境網絡條件一緻。複用MySQL的合理性需評估。為避免影響QA環境，一部分人會避免使用QA環境。
1.2、特性環境易用性差
1.2.1 建立環境過程繁瑣
曆經環境建立、資源申請、分支建立、合并部署四個過程。鍊路較長，前後銜接較差。
1.2.2 了解泳道概念複雜
教育研發人員泳道設計成本高，在實際操作時人員定義泳道辨別困難。
1.2.3 缺乏最佳實踐缺失
建立特性環境後部署成功，缺乏最佳實踐，以至于建立後不知如何使用。
1.3、特性環境可靠性低
1.3.1 中間件初始化條件嚴苛
目前僅支援RabbitMQ。（底層是利用AMQP代理及泳道建立時建立RoutingKey及Queue來實作泳道特性。）但消息隊列前置條件較為苛刻：需将Omega應用關聯的隊列關系儲存正确，否則即便建立了Omega應用的特性環境亦無法正确建立特性環境消息隊列。
且建立隊列服務本身可能存在不可用的情況。（發生過一件事，特性環境建立調用了建立隊列的開發API，但後續API由于添加了權限鑒定，導緻隊列建立失敗）。
1.3.2 中間件本身不支援泳道
Dubbo采用的ZooKeeper注入Tag方式實作。但在某些特性版本的ZooKeeper中可能會丢失Tag辨別。
1.3.3 複用中間件資料錯亂
缺乏對MySQL等持久化資料庫的使用規範。存在不同環境處理相同資料的情況。
02
解決方案分析
針對三個問題：
1、穩定環境初始化難；
2、特性環境易用性差；
3、特性環境可靠性低。
定制三大方面政策。
2.1、 穩定環境初始化難
2.1.1 忽略環境隔離問題
将日常（Daily）、QA（測試）、Stable（穩定）統一歸為Test環境。打通各個環境互相通路。可複用各個環境的中間件配置。
2.2、特性環境易用性差
2.2.1 優化特性環境建立流程
将原有步驟「特性環境建立」、「泳道辨別選擇」、「環境資源審批」、「建構參數配置」、「開啟平台賦能」、「特性分支內建」等濃縮成一個「加入特性環境」按鈕。僅通過一個表單即可快速的建立特性環境。
2.2.2 部署自有服務進行模拟實踐
基于Omega自身，采用特性環境進行新功能的測試。在新功能的測試過程中發現、收集、解決問題，并輸入自身的思考及最佳實踐方案。為後續疊代優化提供思路及方向。
2.3、特性環境可靠性低
2.3.1 編寫測試用例
驗證現有功能的可靠性。
2.3.2 修複現存異常
基于測試用例的結果，修複現存的異常問題。
2.3.3 編寫使用文檔
基于現狀編寫使用功能的前置條件（如RabbitMQ特性功能正确開啟需滿足Omega應用在ZMS平台正确關聯Queue，否則将無法正确建立隊列）
03
解決方案實踐
| 序号 | 事項 | 負責人 | 說明 |
| 1 | 編寫測試用例 | 熊超 | 驗證特性環境現有功能可靠性：HTTP、Dubbo、SpringCloud（Eureka、Nacos）、RabbitMQ。 |
| 2 | 修複泳道異常 | 熊超 | 修複RabbitMQ建立失敗問題。補充完善RabbitMQ正确建立的前置條件。 |
| 3 | 優化泳道建立 | 黃成 | 新增基于分支及關聯Jira建立特性環境按鈕。自動初始化特性環境相關配置，包括但不限于：開啟增量代碼覆寫率收集（SuperJacoco）、環境配置初始化（記憶體及CPU）、運作時變量繼承（LinuxEnv及Hosts）、Maven建構參數（MavenRepo）等。 |
| 4 | 驗證可行性 | 黃成 | 基于Omega本身前後端驗證特性環境建立及特性環境的應用。 |
04
實踐思考沉澱
在真實的實踐過程中，我遇到了以下四個問題：
1、Omega本身穩定環境部署究竟應該對接哪些中間件？
2、Omega特性環境部署需要哪些前置條件？
3、Omega特性環境建立後應該如何使用？
4、特性環境與原有環境比起來優勢有什麼？
我相信大家在使用Omega特性環境時也會遇到相同的問題，故撰寫于此，已飨視聽。
4.1、穩定環境究竟應該對接哪些中間件？
由于曆史原因（無QA介入），與業務線不同的是，基礎架構中心絕大部份應用無KQ環境。故Omega在部署穩定環境時遭遇了第一個問題：對接上遊系統是否需通知上遊系統部署穩定環境？對接中間件是否需對接穩定環境中間件？
在經過短暫思考過後，我發現對接全部的穩定環境應用及中間件既無可能、亦無必要。
原因如下：
1、應用開發者在需要特性環境時，無法即刻推進全部的上遊應用接入穩定環境；且即便不依賴于上遊的穩定環境應用及中間件，亦可對接原有環境的應用及中間件進行特性環境開發。
2、後續需将多個應用串聯至特性環境時，再做改造，也來得及。因為若多個應用歸屬于内部自不用說，若跨業務線，亦可基于相同的目标及技術基礎進行協作部署。
故基于此判定：
我将Omega的前後端（omega-ui及omega-api）部署至穩定環境僅對接原有環境的應用及中間件。
omega-api對接的大多數為Daily（KT日常）環境的應用及中間件，如Message（消息推送）、Opst（工單）、SIA（定時任務）；
而omega-ui亦為Daily（KT日常）環境的服務，如私有雲登入。
4.2、特性環境部署成功，需要哪些條件？
在實踐過程中，我所遭遇的問題共分為兩部分：後端及前端。
後端部署遭遇問題：
1、 跨環境通路
a) 需在穩定環境、特性環境通路日常環境服務。通過hosts配置進行跨環境通路。此功能僅在基礎平台内部可執行。業務線絕大多數均部署KQ環境且穩定環境一部分均已部署。
前端部署遭遇問題：
1、 前端編譯問題
a) 編譯穩定環境需新增npm run build:stable。需在index.js中添加stable.env.js建構配置檔案。
4.3、特性環境部署成功後，如何使用？
1、分析：共計三種情況：1、僅前端開發；2、僅後端開發；3、前後端均需開發。由于Omega僅涉及到Web端開發，，故抛磚引玉，僅闡述Web端開發的最佳實作，移動端複刻同理。
2、前提條件：前端與後端均已部署穩定環境。且采用穩定環境域名通路。Omega前端通過omega.ks.ziroom.com通路，且對接了omega-api.ks.ziroom.com後端。
3、特性環境部署邏輯：開發即部署，不開發即無需部署。 如僅開發前端則僅部署前端至某個特性環境，後端同理。
4、使用方式：依賴于Chrome插件ModHeader，該插件作用：在Header中添加KeyValue。在自如中實踐即添加ziroom-env-tag及JiraID用于泳道辨別。
詳細闡述說明：
原則上來說，大家僅需遵循2、3、4即可。之是以這樣做的詳細解釋如下：
還是基于1分為三類場景：1、僅前端開發；2、僅後端開發；3、前後端開發。
1、 僅前端開發：部署至特性環境後。由于前端已部署，故通過omega.ks.ziroom.com帶标簽通路會自動FullBack至特性環境的前端應用，而由于并無特性環境後端，故會請求會由穩定環境後端提供。
2、 僅後端開發：同理可得，僅部署特性環境後端。由于前端并未部署，即便omega.ks.ziroom.com帶标簽，依舊會通過穩定環境的前端傳回頁面，同時通路特性環境後端服務。
3、 前後端開發：均使用特性環境應用提供服務。
4.4、特性環境與原有環境比起來，優勢有什麼？
如果僅是為了用而用，難免存在自嗨的嫌疑，拿着錘子找釘子的事情無疑是對成本的極大浪費。那麼在我個人的實踐過程中，存在哪些對我而言更有價值的收益，以供大家參考呢？
1、 排查異常更獨立。
a) 由于接入了代碼覆寫率掃描工具，可以将增量代碼掃描出來。在遭遇異常中斷時，可以快速定位到究竟是在哪行代碼中斷的，以便在測試環境快速定位問題。
2、 環境隔離互不幹擾。
a) 若存在多條并行測試時，不會因為并行測試造成互相間的邏輯影響。如功能A依賴于某開關「開啟」但功能B依賴于某開關「關閉」。在不同環境中即可通過Mock的方式進行調試測試。
3、 泳道鍊路調試
a) 若存在跨多應用的需求，無需啟動全量應用覆寫測試鍊路了，有益于降低業務線測試的測試鍊路部署的成本。
05
後記
之是以采用「絕知此事要躬行」作為标題，實際上也對應了軟體開發中的一句話「吃自己的狗糧」。雖然特性環境主要閱聽人是業務線研發，但若不親身實踐，我們亦無法得知在真實使用過程中到底會遭遇哪些問題。唯有親身實踐後，才能在實踐中發現問題，最終切實的解決掉其存在的困難。
作者:網際網路平台-黃成
來源-微信公衆号:自如技術
出處:https://mp.weixin.qq.com/s/oG7jqA3px8wqb2epPUraUw