善事利器 - 我是如何在藥師幫掌店易專案落地 Zadig 的

語言: CN / TW / HK
時間 2022-05-30 02:02:47
主題:
開源之夏第三屆火熱來襲，高校學生參與贏萬元獎金！>>>

背景介紹

藥師幫是專注於醫藥智慧供應鏈的綜合服務平臺，而掌店易專案是負責其中藥店 ERP 系統這一環節的，為全國藥店搭建基礎設施，提供增效減本的 SaaS 解決方案。

從 2015 年起，藥師幫公司內部逐漸形成了自己的研發體系，其中包括開發，部署，測試，上線等一系列流程。近兩年起步的掌電易專案，自然繼承了公司內部的這套流程，並基於原有的流程上，進一步優化擴充套件

事出有因

我們過去的釋出部署模式（如下圖示）：傳統的部署流程，是採用自定義的 Shell 指令碼，從程式碼倉庫拉取程式碼，在物理機本地進行編譯生成 JAR 包，然後上傳到映象倉庫，並將提前定義好的各個微服務的 Yaml 檔案應用更新到 K8s 叢集上。
 
這種原始的部署流程存在以下一些痛點：
 
  1. 自定義部署指令碼的開發和維護成本高
  2. 開發人員提交程式碼後需要手動去觸發部署指令碼，一方面是可能會被遺忘，另一方面是很被動
  3. 開發人員執行部署指令碼後，需要等待部署成功後再通知到測試組開啟測試，中間存在許多時間被耽擱
  4. 編譯部署過程依賴於物理機環境，不同環境(開發服/測試服/正式服)需要做到依賴環境一致很困難
  5. 沒有對所有釋出部署流程的一個情況做相應的記錄
  6. 需要維護大量微服務的 Yaml 配置檔案，以及其中的變數
 
痛定思痛，於是開始研究起持續性交付解決方案。
 

利器善事

都說工欲善其事必先利其器，好的工具是解決問題的關鍵，所以對持續性交付解決方案的利器選型就至關重要了。

一開始從身邊同事渠道，和網友渠道，一致推薦使用 Jenkins 那套自動化部署流程，都說它是持續整合界的神器，你想用它幹啥都行。 公司內部還有一個部門在使用 GitLab 的 CI/CD，直接完成程式碼提交後觸發不同條件下的釋出部署流程，加上它新版的互動介面和統計介面做的比較優美，讓人看的垂涎欲滴，欲罷不能啊。

可是，否定 Jenkins 我個人找了兩個理由，一個是介面真的太醜，互動真的太影響心情了，另一個是它需要每個專案裡維護一個 Jenkins 流程指令碼。 否定 GitLab CI/CD 的原因同樣是因為它需要在專案裡維護一個 gitlab-ci.yml 的配置檔案，和程式碼專案"耦合"是我個人不能接受這兩個方案的最主要原因。

於是在知乎上翻找關於 "devops" 的所有文章，偶然間看到這篇 位元組和騰訊都在使用，DevOps工具Zadig究竟有何魔力 - 知乎 (zhihu.com)，文章裡的幾個介面截圖直接告訴了我的直覺，這就是我腦海中一直想要的解決方案。 於是。。。。。。

 

學習摸索

上手 Zadig 的最大感觸就是簡單，學習成本很低，我總結就是：
 
  1. 安裝部署簡單：只需要一行命令，一個指令碼，一個K8s 叢集，一個名稱空間，就可以模擬出來一個環境進行學習和技術預研。 這一步就極大降低了入門的門檻了。
  2. 詳細的官方文件：對系統各個角落的功能都做了仔細的介紹說明，並提供了多個場景下的最佳實踐方案，其中 Spring Boot 專案持續交付 的文案給我們提供了很多的幫助。
  3. 社群活躍度高：微信群裡問題的及時反饋和跟進，以及後續有針對性的，點對點的飛書文件跟進問題進度，為我們處理解決問題提供了多方面渠道，這個非常 nice~

在其他產品上是很少見到這種多渠道，點對點溝通解決處理產品問題的思路的。 說實話，當初被 Zadig "找上門"，專門拉了個群，還建了個飛書問題跟進文件，還遠端語音溝通問題點，真的是受寵若驚的感覺呀！極少有的一種使用者的反饋被產品重視的感覺~

起步學習 Zadig 時，非常建議先看一遍官方文件，第一次可以先簡單從頭到尾過一遍，心裡大概有個底，涉及到哪些操作步驟，操作流程，有哪些功能，可以解決自己的哪些痛點。 因為本人遇到比較尷尬的一件事情是，當一鍵安裝好 Zadig，就一頭扎進去使用了，剛開始連環境，服務，構建這幾個先建立哪個都搞不清楚，自己摸索會遇到一些沒必要浪費時間的坑的，也許文件上一句話就解決了困擾自己半天的疑惑。

測試落地

具體落地還是要從開發服和測試服啟動，目前已經通過 Zadig 完成開發和測試兩個支線的持續交付流程。

 

 

後續規劃在正式服上搭建一套 Zadig 環境，並打通開發/測試兩個環境，統一一套 Zadig 解決三個環境下的持續交付流程。 計劃正式服的釋出是已經經過測試組充分檢驗過，沒有問題的交付物進行釋出，而不需要再經過一輪拉取程式碼，編譯打包的工作流程了。

目前測試中心和交付中心兩個模組還沒有深入使用，也是後續的規劃方向。

預計後面正式服落地後，會在公司內部其他團隊做一次分享，畢竟獨樂樂不如眾樂樂嘛。 技術預研期間已和其他專案技術人員溝通過關於 DevOps 這方面的乾貨，向他們推薦 Zadig，大家都很是期待。

 

總結經驗

Zadig 打通了程式碼倉庫、映象倉庫、K8s 服務叢集，實現了研發人員和測試人員之間的無縫聯動，自從上了 Zadig 後，之前的痛點都不再痛了 ^_^

  1. 不需要再開發和維護大量指令碼
  2. 研發人員提交程式碼後，通過工作流自動觸發部署，成功後通過企微 Webhook 通知到測試組的企微群裡
  3. 打包編譯都是在 Docker 容器中完成，脫離對物理機環境的依賴，交於 Zadig 統一環境管理
  4. 研發部署過程中，所有流程都有記錄可循，方便追溯、定位問題
  5. 微服務的 Yaml 配置檔案可以基於統一一個模板檔案，各個微服務也都有各自的變數管理
 
團隊內部對 Zadig 認可度是很高：
 
  • 研發人員提交程式碼後直接根據企微群通知就可以知道釋出構建的結果是成功還是失敗，如果失敗了也可以快速通過連結跳轉到構建命令提示介面，檢視原因，為研發人員節省了大量之前花在編譯構建釋出流程的時間
  • 測試人員也可以根據企微群的服務釋出記錄提示，看到哪些缺陷已經被修復部署了，節省了和研發人員之間的溝通成本，避免了研發人員已修復的 Bug 但是忘記通知測試人員的情況
 
當然，以上是基於 Zadig 在藥師幫掌店易專案中使用到的功能，以及重點解決的痛點的總結歸納，Zadig 還有其他優勢，比如 整合統一賬戶登入 ， 完善的許可權管理 ， 不同環境搭建管理等等，還有待於其他場景下的深入使用 Zadig 功能。

建議期待

希望 Zadig 越做越好，下面僅以個人觀點提幾個建議和期待:
  1. 關於整合介面自動化測試流程的實踐（類似現在比較流行的 Apipost，Apifox 這類產品），接下來會重點研究和實踐 Zadig 測試中心模組，希望把團隊的自動化測試也做起來，解決測試端的痛點
  2. 是否可以考慮接入 Istio，實現服務的灰度釋出，金絲雀釋出等應用場景
 
Zadig，讓工程師更專注創造！歡迎加入  開源吐槽群🔥
   

 

「」