我們公司是如何做到高效並行測試的?

童同學發表於2022-01-24

“下午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會將其轉發至你所指定的測試通道。這些功能剛好解決了我和團隊耗時排隊測試的困境,滿足了團隊測試的需求:

  1. 團隊內部並行開發與聯調測試的需求,大家無需再爭搶使用測試環境
  2. 按時交付專案的需求,避免了因為測試環境不夠導致專案延期的情況

我們無需調整已有的技術棧和架構,KubeOrbit會適配現有的微服務,還能夠隔離不同測試通道之間的通訊。但是在產品的使用過程中,我發現還需要有較多的人工操作,增加了這個工具的使用門檻。如果能夠把這些流程自動化,會給使用者體驗帶來較大幅度的提升。剛好從公眾號得知產品在GitHub全部開源的訊息,我也打算好好研究一下,持續關注這個專案和平臺,希望未來有更好的體驗。

相關文章