思創(chuàng)科技作為一家公交行業(yè)的互聯(lián)網(wǎng)轉(zhuǎn)型企業(yè)，在規(guī)模較小的時候開發(fā)人員能夠擔(dān)任“全棧工程師”。所有的研發(fā)步驟節(jié)點(diǎn)都可以由開發(fā)人員參與完成項(xiàng)目迭代上線。但是隨著公司的發(fā)展，項(xiàng)目的增長和需求的繁多。研發(fā)人員在進(jìn)行代碼驗(yàn)證的時候，花費(fèi)了太多的時間。無法全身心投入到研發(fā)過程當(dāng)中。

同時針對于研發(fā)人員天馬行空的想法驗(yàn)證也有著局限性。一個行業(yè)的創(chuàng)新，必定是需要驗(yàn)證眾多天馬行空的想法，才能最終實(shí)現(xiàn)突破性的創(chuàng)造。但如果依舊按照之前傳統(tǒng)的研發(fā)體系，那么軟件研發(fā)創(chuàng)新的可能性就會隨著時間的發(fā)展，研發(fā)人員的精神疲憊，無法獲取靈感創(chuàng)新。

IT 技術(shù)發(fā)展自身技術(shù)的跟進(jìn)和變革（虛擬化無法滿足現(xiàn)有狀態(tài)）

傳統(tǒng)的虛擬化在項(xiàng)目中已經(jīng)逐步地感到“疲憊”。在項(xiàng)目申報中，服務(wù)器一般都會有著部分的冗余空間，但是恰恰就是這部分的冗余空間，在某些時刻就是浪費(fèi)。我們需要做到一個變革，一場能夠?qū)?IT 利用率達(dá)到最好的變革。

DevOps 和容器化隨著研發(fā)瓶頸逐漸出現(xiàn)在我們后續(xù)的工作中。

DevOps 的探索

為什么選擇 Zadig？

起初我們選擇的是 Jenkins ，因?yàn)?Jenkins 在業(yè)內(nèi)太有名。隨意在馬路邊上拉上一個 IT 從業(yè)者，你問他 Jenkins 是什么，他肯定知道。哈哈。隨后的落地中，我們也確實(shí)是使用著 Jenkins 去做一個探索。起初想做到如下，但是效果不太理想。

• Jenkins 首先創(chuàng)立的初衷是針對于主機(jī)服務(wù)，在創(chuàng)立的時候并沒有為 Kubernetes 留下一道方便之門。
• Jenkins 做持續(xù)集成部署有著繁多的 Pipeline 和 Jenkinsfile，Dockerfile 以及各類 K8s 服務(wù) Yaml 文件。在文件管理上略顯雜亂。這些東西都是比較有規(guī)律的文件，缺乏統(tǒng)一管理。且如果 Jenkins 是包括了以往傳統(tǒng)的主機(jī)部署項(xiàng)目的話是可以說是繼續(xù)探索下去的，但是在大規(guī)模實(shí)現(xiàn)容器化編排的現(xiàn)在 Jenkins 在我們這就有點(diǎn)乏力。
• 但是 Jenkins 有著靈活的插件和 Pipeline ，可以實(shí)現(xiàn)人工介入發(fā)布，這是我們比較喜歡的一點(diǎn)。但隨著項(xiàng)目的上線和使用，發(fā)現(xiàn)他的并發(fā)構(gòu)建在現(xiàn)有環(huán)境下較慢故暫時擱置。
• Jenkins Pipeline 在微服務(wù)發(fā)布項(xiàng)目中，需要修改 Pipeline ，造成不必要的麻煩。
• Jenkins 無法對服務(wù)的發(fā)布順序做改變，只能通過腳本的形式手動選擇順序發(fā)布。

在后續(xù)的工作中，發(fā)現(xiàn)了 Zadig ，他成為了我們高效研發(fā)的“尚方寶劍”。

初識 Zadig

Zadig 其實(shí)我覺得接觸起來非常容易，前提是你要了解基本的 K8s 概念和你需要構(gòu)建服務(wù)的語言基本情況，這樣你使用起來就是直接起飛。

Zadig 在我們這有著高效的研發(fā)流程，具體體現(xiàn)在：

1. 高效管理 K8s 服務(wù) Yaml，Helm，微服務(wù)的 Dockerfile 的模版，完美解決了 Jenkins 中繁多的文件問題
2. Zadig 完美支持云原生項(xiàng)目和主機(jī)項(xiàng)目，可以實(shí)現(xiàn)魚和熊掌，我都要！
3. 在我們扁平化的環(huán)境下， Zadig 的效能能夠完美覆蓋我們的所有場景
4. Zadig 環(huán)境管理能力很強(qiáng)大，能夠提供其他工具無法提供的環(huán)境復(fù)制功能，在不同環(huán)境下支持不同的 Configmap，環(huán)境變量等
5. Zadig 進(jìn)行 CI 提速較為明顯
6. 具有強(qiáng)大的統(tǒng)計數(shù)據(jù)模塊

我們從 1.6 版本就開始使用 Zadig ，那個時候 Zadig 還是一個比較稚嫩的 CI/CD 工具，但是現(xiàn)在都已經(jīng)發(fā)版到 1.12 了，具有太多有用的功能了。

那個時候我們就是十分看重 Zadig 對 Kubernetes CI/CD 的管控力。只需要定義好相關(guān)服務(wù)的 Yaml ，這個 Yaml 可以從模板庫中提取，就十分的 Nice。填寫相關(guān)的服務(wù)參數(shù)，就可以實(shí)現(xiàn)運(yùn)行了。并且他可以自定義運(yùn)行順序，可以說非常棒。

在后續(xù)對 Zadig 的關(guān)注中，我們發(fā)現(xiàn)他逐步的推出了新的產(chǎn)品。我們對 Zadig 也十分充滿信心。在后續(xù)我們也嘗試過升級，但是那個時候自己電腦上 VMware 做虛擬化升級測試是可以，信心滿滿的去生產(chǎn)做升級。好家伙，什么服務(wù)都起來了，但就是無法訪問 UI 界面。只能回退，后續(xù)我們在和官方接觸后才發(fā)現(xiàn)是 Istio 和 Zadig 的網(wǎng)關(guān)沖突，在升級的時候關(guān)閉了相關(guān)的參數(shù)后才正常升級，體驗(yàn)到了更好的產(chǎn)品。通過這個事件我也體會到了開源產(chǎn)品社區(qū)和用戶之間的聯(lián)系更緊，那么問題定位也能更方便，不斷的使用產(chǎn)品，不斷的反饋，社區(qū)不斷的打磨，鑄就一個更為強(qiáng)大的產(chǎn)品誕生，未嘗不是一件美事。

怎么判斷 Zadig 是否適合你

如果你們公司的是和我們一樣在推動數(shù)字化轉(zhuǎn)型，容器化編排，那么 Zadig 十分適合你。

如果你們公司用著 Jenkins 做傳統(tǒng)的主機(jī)發(fā)布管理，這個時候要上 Kubernetes 實(shí)現(xiàn)容器化，那么 Zadig 同樣適合你們，可以做到 Jenkins 和 Zadig 的集成發(fā)布。

如果你們公司的項(xiàng)目較為扁平化，那么 Zadig 可以基本覆蓋 95% 的場景，加上 Zadig 眾多的優(yōu)勢，何樂不為呢？

如果你們公司剛剛開始進(jìn)行云原生探索，那么 Zadig 是你們的不二之選，上手快，社區(qū)活躍度高。問題響應(yīng)之快，絕對可以為貴公司 DevOps 理念的落地提供技術(shù)支撐。

Zadig 實(shí)現(xiàn)的價值

Zadig 不僅僅是一個優(yōu)秀的 CI/CD 工具，他更是 DevOps 文化的踐行者。通過 Zadig 我們實(shí)現(xiàn)了高效研發(fā)，在研發(fā)人員的每日研發(fā)利用率上對比以往做到了更大的提升，省出寶貴時間去創(chuàng)造更多產(chǎn)品價值。

• 針對需求迭代，做到了每日服務(wù)需求有更新
• 針對開發(fā)驗(yàn)證，可以做到集成環(huán)境資源的收縮自如
• Zadig 不僅實(shí)現(xiàn)了自身的企業(yè)價值，還幫助解決了我們這些軟件企業(yè)發(fā)展中的許多瓶頸問題。

使用情況總結(jié)

• 當(dāng)前思創(chuàng)科技產(chǎn)品業(yè)務(wù)線 5 條，其中 3 條業(yè)務(wù)線都已完全接入 Zadig，其余 2 條業(yè)務(wù)線屬于傳統(tǒng)業(yè)務(wù)，更新頻率較低。
• 通過 Zadig 管理了3個集群，其中 2 套集群為遠(yuǎn)端業(yè)務(wù)集群。部分環(huán)境無法通過 Kubernetes 去編排容器實(shí)現(xiàn)遠(yuǎn)程發(fā)布，通過zadig的主機(jī)項(xiàng)目，實(shí)現(xiàn)遠(yuǎn)程容器發(fā)布，方便后續(xù)的業(yè)務(wù)遷移。
• 運(yùn)行環(huán)境 17 個其中 12 個測試、5 個生產(chǎn)，共計 200+ 個應(yīng)用程序，實(shí)現(xiàn)了 4000+ 次自動化構(gòu)建和部署，部署成功率 99% 以上 從發(fā)布頻率上看，以往都是有開發(fā)人員主動介入發(fā)布，在本地通過打包的形式部署在服務(wù)器上，發(fā)布。一天發(fā)布的頻率大約在 10 次上下。在接入 Zadig 之后代碼更新迭代的頻率得以飛速提升，慢的一天也是30 左右，快的一天 70 余次。