譯聞 Jenkins與持續交付的若干問題

2021-09-23 16:56:09 字數 2504 閱讀 1131

關於譯者ghostcloud

ghostcloud(中文名:精靈雲)是成都精靈雲科技****旗下的基於docker的paas/caas平台品牌。公司成立於2023年,核心團隊由來自emc、veritas、華為、ibm、microsoft的核心技術主管和架構師組成。精靈雲作為國內首批從事容器虛擬化研發的企業,為企業級行業客戶提供針對網際網路化、私有雲管理平台、大資料業務基礎架構的平台服務,在國內docker社群貢獻排名前三。主創團隊曾參與beego開源專案研發,並主導發布《docker容器實戰:原理、架構與應用》一書。ghostcloud因容器技術而生,致力於為多個領域的「網際網路+」轉型企業提供服務,是一流的企業級容器雲服務專家。

今天我們和大家詳細聊一聊一直非常受歡迎的開源工具——jenkins。

眾所周知,jenkins在軟體開發流程中非常有用,是一款很棒的工具,但jenkins和其他ci伺服器一樣,在軟體交付過程中也會或多或少出現一些問題。軟體交付團隊往往在部署jenkins以及這類工具的時候會犯錯,使得開發效率變低,削弱了團隊的敏捷開發能力,同時也失去了使用最新技術創新所需的靈活性。

使用jenkins會出現的若干問題

問題1:jenkins的外掛程式太多

外掛程式不一定是壞事,當它們都使用正確時,確實是很好的資源。使用者可以向其使用的工具中增加額外的功能,這當然是最好的。但jenkins的外掛程式並不能為平台提供核心功能以外的任何可拓展功能,相反,在大多數情況下,使用jenkins外掛程式,團隊只能完成基礎的開發工作。

但如果你想通過jenkins外掛程式來做任何事情,這都是欠妥的。因為這就意味著交付團隊要花更多的時間來安裝和配置外掛程式,如此才能開始愉快的工作。然而還有乙個更大問題,那就是大多數jenkins的外掛程式都由第三方編寫的,質量不一樣,而且在沒有詳細描述的情況下可能會不支援。

可見,構建基於第三方外掛程式的軟體交付鏈,並不是乙個保證可用性或穩定性的好辦法。

問題2:jenkins不是為docker而設計

早在2023年上半年,在設想容器和微服務作為軟體部署的首選基礎設施之前,ci伺服器就已經存在。它確實是一種相對較老的技術,通常是devops的一部分。

因此,傳統的ci伺服器不能幫助團隊使用像docker容器這樣的基礎架構,他們只能通過大量外掛程式與docker進行不恰當的整合。然而事實上,大部分外掛程式由第三方提供,並在與docker相關的平台上使用。雖然jenkins為docker提供了14+個不同的外掛程式,但其中六個是針對docker的核心平台使用。

jenkins與大多數其他ci伺服器一樣,都建立在裸機伺服器和虛擬機器時代。後來,在docker的支援下才進行了處理。所以在這個傾向於docker的大環境下,這並不是ci伺服器執行的好方法。

問題3:jenkins不能較好的支援微服務

jenkins和大多數ci伺服器一樣出現在docker之前,也出現在微服務流行之前。 有些人早在2023年的時候就在開展soa工作, jenkins在那時也首次被使用。而在二十世紀八十年代初,微服務的概念就已經存在。但直到docker出現,微服務才開始真正實現。

看到這裡,或許你能猜到jenkins並不能很好支援微服務, 而事實上也是如此。因為jenkins缺乏對整合和一次測試多個服務的支援,而這些都是微服務環境下的基本功能。

除非你計畫多個流水線的開發,否則jenkins在幫助開發下一代微服務應用程式方面做得並不是太好。

問題4:ci!=cd

jenkins和ci伺服器最大的問題是,有時交付團隊會將持續整合(ci)與持續交付(cd)混在一起。而事實上,這兩者是不同的。

ci是cd的一部分,但是要實現完整的cd,需要的不僅僅是ci伺服器。

無論什麼時候,cd都需要自動發布到當前使用環境中。這需要如「steps」之類的工具來實現,將軟體交付任務自動化到ci伺服器的範圍之外。cd這一過程需要工具和渠道,使軟體交付團隊達到無縫協作。

當建立乙個ci伺服器時,就馬上考慮軟體交付工作完成,這本身就是在犯一大錯誤。

改變jenkins思路

為什麼經驗豐富的軟體工程團隊會犯這樣的錯誤?這不是因為他們不了解,亦或是無法跟上最新的創新。問題在於團隊被誤導去嘗試效仿大企業,並使用最有效的軟體交付手段,想要做成和google、netflix一樣。這些企業著力於利用開源工具鏈和大量基礎設施,構建出非凡的敏捷軟體交付通道。

然而,這些公司之所以能做到這些,絕不僅僅是因為他們的部署工具,而是他們的思路。這就像是你能使用像google一樣的工具,但你不能像它那樣的高效。較小的企業並不能意識到這一點。只有當他們真正擁有正確的思路和過程時,才能克服jenkins這類工具帶來的侷限性,並優化他們的軟體交付流程。

沒有工具鏈是完美的,但當你有這樣思路時,同樣可以實現軟體交付完美(或至少與其相近的東西)。如果你的軟體交付方式仍然圍繞jenkins建立,你無疑會錯失做的更好的機會。要實現這些仍需要研發思路與過程的革新。

CICD 持續整合與持續交付

持續整合與持續交付是軟體開發和交付中的實踐。我們專案中一直在踐行持續整合 ci continuous integration 持續交付 cd continuous delivery 未能達到理想狀態,只能實踐一部分。這篇文章用於總結ci cd的實踐。什麼是持續整合?軟體開發中,整合是乙個很可能發生未...

持續交付的Mesos與Docker匯入篇

變革這個詞在當今的數位化時代司空見慣,it技術每過一段時間就會有一起革新,從web2.0 虛擬化 雲計算 大資料 微架構 devops再到今天的容器docker與mesos。docker的出現方便了應用的測試 部署 與公升級,其將各種應用程式和它們所依賴的執行環境打包成標準的container im...

持續交付的Mesos與Docker匯入篇

變革這個詞在當今的數位化時代司空見慣,it技術每過一段時間就會有一起革新,從web2.0 虛擬化 雲計算 大資料 微架構 devops再到今天的容器docker與mesos。docker的出現方便了應用的測試 部署 與公升級,其將各種應用程式和它們所依賴的執行環境打包成標準的container im...