CI/CD是什么?它如何幫助我們更快地遷移、部署?它值得我們這么興師動眾嗎?本文將一探究竟。
CI/CD的全稱是Continuous Integration and Continuous Delivery,意思是持續集成和持續交付,它自動化了從最初的代碼提交,一直到部署的開發過程,消除了大部分的人工干預成本。
CI/CD流程負責構建、測試和部署新代碼到生產環境。Prometheus曾經這樣評價:它使軟件團隊能夠更快地部署質量更好的軟件。聽起來很美好,但它在真實環境中有效嗎?答案是取決于系統本身的復雜性。
讓我們將CI/CD拆解出來并分別討論。CI的爭議較小且更為常見。簡而言之,它是使用自動化使團隊能夠高效、頻繁地將代碼更改合并到共享存儲庫的一種做法。每個提交都會在CI服務器上觸發一個自動化工作流,該工作流運行一系列任務以確保提交可以安全地合并到主分支中。一個好的CI流程依賴于一組好的測試。維護一組具有足夠覆蓋率且不脆弱的測試并非易事,高測試覆蓋率通常需要更長的時間才能運行,這會影響開發人員的生產力。
這是一個艱難的平衡操作,但值得付出正確的努力。
CI中常用的工具有哪些呢?一個好的源代碼管理系統是一切的基礎。
Github是一個非常流行的例子,它擁有構建軟件所需要的一切,包括源代碼、測試腳本和構建軟件應用程序的腳本。
有許多工具可以管理CI流程本身。GithubActions和BuildKite是當今常見的案例,Jenkins、CircleCI和TravisCI也很普遍,這些工具主要用于管理構建和測試任務。
有許多用于編寫和運行測試的測試工具,這些工具通常是特定于語言和生態系統的。
例如對于JavaScript而言,Jest是單元測試框架,而playwright和cypress則是常見的web應用程序集成測試框架。
構建工具則更加的多樣化且依賴于特定的生態系統。
比如Greadle就是一款強大的Java構建工具。JavaScript構建的生態系統非常碎片化,很難跟蹤。webpack是一款標準化的工具,有很多新的構建工具聲稱要快得多,但它們的可擴展性其實還不如webpack。
接下來我們看一下CI/CD中CD的部分。
CD就是持續部署。老實說,真正的持續部署是很難的,它確實存在,但在實踐中并不具備CI那樣的普遍性。
許多團隊只在最基本的系統類型上練習CD。這些系統通常不會過時,例如API或Web服務器層,通過良好的生產監控,這些系統可以以最小的風險實現持續部署,不僅不會過時,而且回滾通常也非常的安全高效。將新功能包裝在功能標志中,使得代碼部署與功能激活分開也是一種常見的做法。它能幫助團隊在新功能引發任何問題時都能快速關閉,而且無需完全回滾。大家或許都知道,對于擁有數億用戶的產品,金絲雀部署也是常見的做法。
在大規模部署新代碼之前,先部署到一小部分高級用戶和員工中,他們在期待新功能的同時又愿意承擔風險以幫助發現bug。這允許團隊在真實環境中測試新代碼,同時在出現問題時限制爆炸半徑。這些技術適用于簡單的無狀態系統。
另一方面,很少有團隊有資源或信念在復雜的主要系統(如數據庫后端集群)或其他類型的主要系統(如websocket集群)上實施真正的連續切換部署。
相反,這些系統通常采用固定的部署節奏,部署過程是手動的,有風險且耗時長,它們需要一個專門的團隊來維護,很少看到這些系統完全連續和自動部署。
那么現在有哪些用于CD的工具呢?
我們前面提到的 Github Actions、BuildKite和Jenkins等工具通常都是用于處理 CD 任務的。
還有一些特定于基礎架構的工具可以使 CD 更易于維護,例如在Kubernetes上,ArgoCD就很受歡迎。
總之,CI/CD是一種強大的軟件開發實踐,可以幫助團隊更快地交付質量更好的軟件。
但是,它并不是一個放之四海皆準的萬能解決方案,其實現程度會因為系統的復雜性而呈現不同效果。
