“下午2-3點我需要佔用測試環境聯調專案，大家不要釋出喔！”
看到群裡的訊息我內心一陣苦惱，由於公司使用的是微服務架構並將其部署在了Kubernetes叢集上，因此團隊負責開發的服務是整個微服務架構其中的一環，整個系統的正常執行需要依賴微服務系統中的上下游服務，這導致每每到了發新版本的視窗期，大家都開始佔用測試環境聯調測試自己開發的功能，導致排隊使用測試環境的情況。
今天是發版日，我也需要將自己的功能釋出至測試環境驗證功能是否正確，有人佔用測試環境的話會導致我無法隨意測試與修復功能，排隊使用測試環境會影響我的釋出效率，到時候又要被產品經理吐槽上線慢了:(
“那我安排在3-4點” 團隊裡另一名工程師在群裡說。
看到測試環境的使用時間不斷被擠壓，我也顧不上是否需真要用一個小時，趕緊在群裡喊“我預期5點開PR合併程式碼，所以4-5點我要測試一下，用好了會通知大家。”
想必各位使用微服務架構的同仁和我有一樣的困擾，那就是“整合測試聯調真的太他丫討厭了！”，尤其一到發新版本的視窗期，測試環境簡直猶如網紅餐廳，大排長龍，各個功能都要測，只能乖乖等。很多公司和我在的這家企業一樣，只有一套測試環境，一到發版前各個專案時間都很緊，全擠一起。尤其現在敏捷開發迭代週期越來越短，測試也越來越頻繁，測試環境著實是不夠用啊。
於是我去找了找目前有沒有能解決這個問題的方案，發現有一些工具鏈可以解決這個排隊耗時問題，比如TeamCode新推出的微服務整合測試工具KubeOrbit，幫助團隊高效測試微服務。
我開啟他發來的產品文件，發現此工具允許我在公司測試環境的Kubernetes叢集中定義基準環境：
$ kubectl label deployment your-deployment version=base我還可以基於基準環境建立不同的測試通道，比如測試環境1和測試環境2：
# Create a test env with name v1
$ kubectl label deployment your-deployment-v1 version=v1
# Create a test env with name v2
$ kubectl label deployment your-deployment-v1 version=v2將自己的服務加入目標測試環境
apiVersion: network.kubeorbit.io/v1alpha1
kind: ServiceRoute
metadata:
name: serviceroute-sample
namespace: sample-namespace
spec:
name: pod-svc
# Add your service to the test env named with v1 by defining trafficRoutes
trafficRoutes:
routes:
- name: v1
labels:
version: v1
headers:
version:
exact: v1
default:
version: base部署到目標測試環境中
kubectl apply -f /path/to/your/serviceroute.yaml使用體驗總結
KubeOrbit工具主要有如下三種功能：在微服務測試環境內建立測試通道，這樣就可以獲得一個單獨穩定的整合測試環境；把需要測試的微服務新增至測試通道中，將它們與其他不同版本的微服務隔離開來；在發起微服務請求的時候指定測試通道，KubeOrbit會將其轉發至你所指定的測試通道。這些功能剛好解決了我和團隊耗時排隊測試的困境，滿足了團隊測試的需求：
- 團隊內部並行開發與聯調測試的需求，大家無需再爭搶使用測試環境
- 按時交付專案的需求，避免了因為測試環境不夠導致專案延期的情況
我們無需調整已有的技術棧和架構，KubeOrbit會適配現有的微服務，還能夠隔離不同測試通道之間的通訊。但是在產品的使用過程中，我發現還需要有較多的人工操作，增加了這個工具的使用門檻。如果能夠把這些流程自動化，會給使用者體驗帶來較大幅度的提升。剛好從公眾號得知產品在GitHub全部開源的訊息，我也打算好好研究一下，持續關注這個專案和平臺，希望未來有更好的體驗。