湖南
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是一種強大的軟件開發實踐，可以幫助團隊更快地交付質量更好的軟件。
但是，它并不是一個放之四海皆準的萬能解決方案，其實現程度會因為系統的復雜性而呈現不同效果。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
