2022中國 DevOps 現狀調查全面啟動！>>>

在日常開發中，能夠支援不同的開發者都有自己的測試環境是一件體感很爽的事情。然而，當業務特點複雜時，一套測試環境中可能包含成千上百個服務，在這種場景下複製一套可用的環境成本極其高。更甚者，因為部分微服務基礎架構的原因，無法完整地複製出多套環境。工程師們只得將就地使用一套測試環境來做日常開發。環境不夠用、管理混亂、多人對同一個服務有變更訴求時必須彼此等待...面對這種情況，只能等等等，忍忍忍！

開發者的煩惱

為解決上述痛點，在最新發布的 v1.11.0 版本中，Zadig 對環境的能力有了進一步的增強：支援開發者用最低成本快速拉起包括部分服務的子環境，在子環境中開發、變更目標服務，並和包括全量服務的基準環境互動來實現自測聯調。下面展開介紹。

Zadig 自測模式

自測模式是 Zadig 為降低環境管理複雜度和部署成本而推出的一種面向開發者的功能模組。當開啟了環境的自測模式後，該環境則成為基準環境，開發者們可以基於基準環境快速複製出屬於自己的自測環境（即：子環境），並且只關注和自己日常改動相關的服務。對於其上下游服務無需理會，基準環境中會提供這部分服務的能力。圖示如下：

適用場景

Zadig 環境的自測模式能力尤其適用以下場景：：

1、有一套完整的測試環境，但多人基於同一套環境協同合作開發，測試環境資源有限，日常存在多名開發者互相等待環境的現象

2、業務規模大，服務數量級可觀，完整複製出多套測試環境的成本高

3、服務相互關聯，受限於基礎架構，完整複製出多套測試環境的難度大

4、日常變更多，大量工程師協作，需要高頻的驗證

如何使用

下面以 simple-service 專案為例來說明如何使用環境的自測模式。專案中環境和服務背景，以及自測聯調需求說明如下：

1. 專案中共包括 3 個微服務 a、b、c，服務呼叫鏈路：a -> b -> c

2. dev 環境為日常完整穩定的測試環境，包括全部微服務 a、b、c

3. 日常會對 a 服務進行高頻改動，希望能對 a 服務進行充分自測，確定其變更可交付

具體操作步驟如下：

管理員：開啟自測模式

在 dev 環境，開啟自測模式：

這時會對自測模式的依賴條件做檢查：

1. 系統無法自動檢查 Tracing 元件，需要管理員自行確保，此處支援較為廣泛應用的 SkyWalking、Zipkin、Jaeger 等。

2. 系統會對 Istio 是否安裝做自動檢查，如果沒有請在環境所在叢集進行安裝

3. 服務呼叫鏈自動檢查，主要依據是有 K8s Service 型別的資源和服務 a、b、c 對應

當開啟自測模式後，dev 環境即成為基準環境。

工程師：日常自測聯調

建立子環境

在 dev 基準環境中通過點選建立子環境，選擇 a 服務可建立包含 a 服務的子環境 dev-test-env1：

子環境服務請求

1、執行以下命令為 default 名稱空間注入 istio label

kubectl label ns default istio-injection=enabled

2、在 default 名稱空間中部署 nginx 服務

kubectl -n default apply -f nginx.yaml # nginx.yaml 可從專案原始碼中獲取

1. 未加 x-env 請求頭，直接請求服務 a，dev 環境中的服務 a/b/c 會處理請求，子環境中無請求流量輸入。

2、增加 x-env: dev-test-env1 請求頭訪問服務 a，子環境中的服務 a 會接收到請求並給出響應，對於請求鏈路上的 b/c 服務，dev 環境中的服務會給出正常響應。

展望

開發者日常工作互動最頻繁的當屬 IDE，Zadig 小夥伴也在緊鑼密鼓完善面向 IDE 的外掛能力，結合Zadig 自測模式，可以讓開發者輕鬆開發聯調又無需切換多個工作介面，大大提升開發者生產力和工作體驗。

自測模式的推出，對降低環境管理複雜度和部署成本效果顯著，同時也非常期待社群小夥伴的反饋，一起打磨完善，同社群一起迭代更好的易用性！

Zadig，讓工程師更專注創造！歡迎加入 開源吐槽群🔥