利用 Zadig 多云周部署千次，持續交付全球業務

iMile 是一家跨境電商物流初創公司，提供中東和拉美等新興市場的物流服務，通過自建快遞團隊、精細化運營和互聯網技術手段，致力于完善跨境物流的末端一公里。iMile 已成長為中東 Top 3 的跨境電商物流服務公司，同時也是當地行業內發展速度 Top 2 的技術效益豐碩的物流公司。

痛點分析

在以往的業務研發過程，我們遇到如下的痛點：

1. 環境治理復雜：dev、fat、lpt、uat、prod 等多套環境分布在不同地區的數據中心，使用 Jenkins 流水線部署交付需要大量人工干預。
2. 研發效率低：研發團隊程序調試、聯調測試環境不夠友好，經常需要在多個環境的不同版本里來回切換協助測試、前后端排查問題，研發時間被占用。
3. 測試資源不足：排期項目與日常迭代經常混合在同一套測試環境里測試，大量代碼變動時部署并行效率不高，影響測試進度。
4. 維護成本高：服務部署使用 Jenkinsfile + YAML 的方式，每個工程需要維護一套配置和腳本，當工程越來越多時，維護成本會越來越重。

Zadig 之旅

在選型 Zadig 之前，我們有多套 K8s 集群，分別部署在了多個不同的數據中心，使用 Kubeboard 進行多集群統一管控，對集群統管暫無其他特殊需求。

偶遇 Zadig

無意中在 B 站看到了 KodeRover Workathon 的線上分享（如下圖），就開始同團隊成員一起研究KodeRover（Zadig）這個產品。發現它與云原生能夠非常完美的結合，多集群服務可統一納管，多流水線并發構建，容器服務可視化交付，面向研發交互友好。

恰巧當時我們研發團隊立項一個重構的項目，需要一套獨立的測試環境來滿足聯調測試任務。我們抱著新鮮的態度就部署了一套 Zadig 集群，計劃通過它來解決這個項目重構的測試環境需求。通過 3 天時間的摸索溝通交流，我們很快在 Zadig 上部署了前后端工程服務到 K8s 集群。

 網絡改造

我們當時網絡狀況是這樣的：辦公內網與云端的開發、測試環境內網是連通的，但到 K8s 的 Service 和容器網絡層并未打通。

重構項目小組開始使用 Zadig 進行項目測試了，但后端研發同學找到我們提了一個需求“我想 debug 這個服務打斷點”。若要實現，則必須將 K8s 內網與辦公網全面打通，我們著手對網絡進行改造，這樣很快研發即可在自己的 IDEA IDE 隨時調用、debug 自己的某一個服務。

全面擁抱 Zadig

全面擁抱云原生屬于運維體系的進化，那么全面擁抱 Zadig 則是研發體系的進化。

一個月后重構項目順利上線，整個項目測試未與原有測試環境使用 NS 隔離，未對日常迭代和其他需求的測試環境造成任何干擾，項目部署變得非常容易，可以邊調試邊查看某個容器日志，對研發同學的操作體驗有了質的提升，已經完全拋棄了原先使用 Kubelet 進入容器的種種麻煩。

有了這個正向的反饋，我們隨即做了一個決定，將開發環境、測試環境等全面接入 Zadig。

經過 4 個月的磨合，我們將所有開發和測試環境的 K8s 集群接入了 Zadig。代碼工程通過 YAML 標準模板導入即可創建部署自己需要的服務。

經過近半年的努力，我們的研發、測試、運維團隊已經將所有服務全面接入 Zadig。接入 Zadig 的服務近 400個，一周部署平均近千次，較大的提升了研發效率，讓研發專注代碼業務實現，測試團隊專注質量提升。測試或者驗證過程可以在幾分鐘內隨時拉起一套環境，供研發和測試使用，減輕了運維工作量和成本。

簡單回顧了一下幾個非常重要的需求細節，我們在這幾個功能完善之后，將所有集群全部接入了 Zadig。

1. 因我們屬于多地域跨云部署，Zadig 默認只有一個鏡像倉庫，我們如果使用同一個倉庫的話，不同集群的鏡像拉取和推送都是通過公網進行，拉取速度受到帶寬制約，且消耗流量非常多。
2. IM 工具消息提示推送文案優化。
3. 項目權限管理的顆粒化控制。

整體收益

Zadig 通過“工作流”整體串聯了 K8s 的各個組件，也串聯起了我們整個研發團隊，極大的減輕了腳本的維護、環境治理，同時上手也非常簡單高效。在項目迭代和交付中起到了極大的幫助，節約了大量的時間成本，讓專業的人做“專業”的事兒，讓項目研發高效并行，減少團隊間的溝通 Gap，給我們的研發交付幫助極大。

總結就是簡單，高效！