背景介紹

藥師幫是專注于醫(yī)藥智慧供應(yīng)鏈的綜合服務(wù)平臺，而掌店易項(xiàng)目是負(fù)責(zé)其中藥店 ERP 系統(tǒng)這一環(huán)節(jié)的，為全國藥店搭建基礎(chǔ)設(shè)施，提供增效減本的 SaaS 解決方案。

從 2015 年起，藥師幫公司內(nèi)部逐漸形成了自己的研發(fā)體系，其中包括開發(fā)，部署，測試，上線等一系列流程。近兩年起步的掌電易項(xiàng)目，自然繼承了公司內(nèi)部的這套流程，并基于原有的流程上，進(jìn)一步優(yōu)化擴(kuò)展。

事出有因

我們過去的發(fā)布部署模式（如下圖示）：傳統(tǒng)的部署流程，是采用自定義的 Shell 腳本，從代碼倉庫拉取代碼，在物理機(jī)本地進(jìn)行編譯生成 JAR 包，然后上傳到鏡像倉庫，并將提前定義好的各個微服務(wù)的 Yaml 文件應(yīng)用更新到 K8s 集群上。

這種原始的部署流程存在以下一些痛點(diǎn)：

1. 自定義部署腳本的開發(fā)和維護(hù)成本高
2. 開發(fā)人員提交代碼后需要手動去觸發(fā)部署腳本，一方面是可能會被遺忘，另一方面是很被動
3. 開發(fā)人員執(zhí)行部署腳本后，需要等待部署成功后再通知到測試組開啟測試，中間存在許多時間被耽擱
4. 編譯部署過程依賴于物理機(jī)環(huán)境，不同環(huán)境(開發(fā)服/測試服/正式服)需要做到依賴環(huán)境一致很困難
5. 沒有對所有發(fā)布部署流程的一個情況做相應(yīng)的記錄
6. 需要維護(hù)大量微服務(wù)的 Yaml 配置文件，以及其中的變量

痛定思痛，于是開始研究起持續(xù)性交付解決方案。

利器善事

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

一開始從身邊同事渠道，和網(wǎng)友渠道，一致推薦使用 Jenkins 那套自動化部署流程，都說它是持續(xù)集成界的神器，你想用它干啥都行。 公司內(nèi)部還有一個部門在使用 GitLab 的 CI/CD，直接完成代碼提交后觸發(fā)不同條件下的發(fā)布部署流程，加上它新版的交互界面和統(tǒng)計界面做的比較優(yōu)美，讓人看的垂涎欲滴，欲罷不能啊。

可是，否定 Jenkins 我個人找了兩個理由，一個是界面真的太丑，交互真的太影響心情了，另一個是它需要每個項(xiàng)目里維護(hù)一個 Jenkins 流程腳本。 否定 GitLab CI/CD 的原因同樣是因?yàn)樗枰陧?xiàng)目里維護(hù)一個 gitlab-ci.yml 的配置文件，和代碼項(xiàng)目耦合是我個人不能接受這兩個方案的最主要原因。

于是在知乎上翻找關(guān)于 "devops" 的所有文章，偶然間看到這篇 字節(jié)和騰訊都在使用，DevOps工具Zadig究竟有何魔力 (opens new window)，文章里的幾個界面截圖直接告訴了我的直覺，這就是我腦海中一直想要的解決方案。 于是。。。。。。

學(xué)習(xí)摸索

上手 Zadig 的最大感觸就是簡單，學(xué)習(xí)成本很低，我總結(jié)就是：

1. 安裝部署簡單：只需要一行命令，一個腳本，一個K8s 集群，一個命名空間，就可以模擬出來一個環(huán)境進(jìn)行學(xué)習(xí)和技術(shù)預(yù)研。 這一步就極大降低了入門的門檻了。
2. 詳細(xì)的官方文檔：對系統(tǒng)各個角落的功能都做了仔細(xì)的介紹說明，并提供了多個場景下的最佳實(shí)踐方案，其中 Spring Boot 項(xiàng)目持續(xù)交付 (opens new window)的文案給我們提供了很多的幫助。
3. 社區(qū)活躍度高：微信群里問題的及時反饋和跟進(jìn)，以及后續(xù)有針對性的，點(diǎn)對點(diǎn)的飛書文檔跟進(jìn)問題進(jìn)度，為我們處理解決問題提供了多方面渠道，這個非常 nice~

在其他產(chǎn)品上是很少見到這種多渠道，點(diǎn)對點(diǎn)溝通解決處理產(chǎn)品問題的思路的。 說實(shí)話，當(dāng)初被 Zadig "找上門"，專門拉了個群，還建了個飛書問題跟進(jìn)文檔，還遠(yuǎn)程語音溝通問題點(diǎn)，真的是受寵若驚的感覺呀！極少有的一種用戶的反饋被產(chǎn)品重視的感覺~

起步學(xué)習(xí) Zadig 時，非常建議先看一遍官方文檔，第一次可以先簡單從頭到尾過一遍，心里大概有個底，涉及到哪些操作步驟，操作流程，有哪些功能，可以解決自己的哪些痛點(diǎn)。 因?yàn)楸救擞龅奖容^尷尬的一件事情是，當(dāng)一鍵安裝好 Zadig，就一頭扎進(jìn)去使用了，剛開始連環(huán)境，服務(wù)，構(gòu)建這幾個先創(chuàng)建哪個都搞不清楚，自己摸索會遇到一些沒必要浪費(fèi)時間的坑的，也許文檔上一句話就解決了困擾自己半天的疑惑。

測試落地

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

后續(xù)規(guī)劃在正式服上搭建一套 Zadig 環(huán)境，并打通開發(fā)/測試兩個環(huán)境，統(tǒng)一一套 Zadig 解決三個環(huán)境下的持續(xù)交付流程。 計劃正式服的發(fā)布是已經(jīng)經(jīng)過測試組充分檢驗(yàn)過，沒有問題的交付物進(jìn)行發(fā)布，而不需要再經(jīng)過一輪拉取代碼，編譯打包的工作流程了。

目前測試中心和交付中心兩個模塊還沒有深入使用，也是后續(xù)的規(guī)劃方向。

預(yù)計后面正式服落地后，會在公司內(nèi)部其他團(tuán)隊(duì)做一次分享，畢竟獨(dú)樂樂不如眾樂樂嘛。 技術(shù)預(yù)研期間已和其他項(xiàng)目技術(shù)人員溝通過關(guān)于 DevOps 這方面的干貨，向他們推薦 Zadig，大家都很是期待。

總結(jié)經(jīng)驗(yàn)

Zadig 打通了代碼倉庫、鏡像倉庫、K8s 服務(wù)集群，實(shí)現(xiàn)了研發(fā)人員和測試人員之間的無縫聯(lián)動，自從上了 Zadig 后，之前的痛點(diǎn)都不再痛了 ^_^

1. 不需要再開發(fā)和維護(hù)大量腳本
2. 研發(fā)人員提交代碼后，通過工作流自動觸發(fā)部署，成功后通過企微 Webhook 通知到測試組的企微群里
3. 打包編譯都是在 Docker 容器中完成，脫離對物理機(jī)環(huán)境的依賴，交于Zadig 統(tǒng)一環(huán)境管理
4. 研發(fā)部署過程中，所有流程都有記錄可循，方便追溯、定位問題
5. 微服務(wù)的 Yaml 配置文件可以基于統(tǒng)一一個模板文件，各個微服務(wù)也都有各自的變量管理

團(tuán)隊(duì)內(nèi)部對 Zadig 認(rèn)可度是很高：

• 研發(fā)人員提交代碼后直接根據(jù)企微群通知就可以知道發(fā)布構(gòu)建的結(jié)果是成功還是失敗，如果失敗了也可以快速通過鏈接跳轉(zhuǎn)到構(gòu)建命令提示界面，查看原因，為研發(fā)人員節(jié)省了大量之前花在編譯構(gòu)建發(fā)布流程的時間
• 測試人員也可以根據(jù)企微群的服務(wù)發(fā)布記錄提示，看到哪些缺陷已經(jīng)被修復(fù)部署了，節(jié)省了和研發(fā)人員之間的溝通成本，避免了研發(fā)人員已修復(fù)的 Bug 但是忘記通知測試人員的情況

當(dāng)然，以上是基于 Zadig 在藥師幫掌店易項(xiàng)目中使用到的功能，以及重點(diǎn)解決的痛點(diǎn)的總結(jié)歸納，Zadig 還有其他優(yōu)勢，比如 集成統(tǒng)一賬戶登錄，完善的權(quán)限管理，不同環(huán)境搭建管理等等，還有待于其他場景下的深入使用 Zadig 功能。