在過去的幾年中，DevOps已成為軟件生命周期中至關重要的一部分，這推動了許多領先的DevOps工具和實踐的發展。您可以找到一系列支持CI/CD流程的工具，Jenkins和GitHub Actions杰出地站在其中。

在本文中，我將對GitHub Actions和Jenkins進行比較，并為你提供洞察力以做出正確的選擇。

Jenkins和GitHub Action簡介

Jenkins是一個免費的、開源的自動化服務器。它幫助自動化軟件開發中與構建、測試和部署相關的部分，促進持續集成和持續交付。

同樣，GitHub Actions是GitHub作為SaaS產品提供的兩個產品中的最新產品。

GitHub Actions 現在讓您更容易在任何平臺上自動構建、測試和部署項目，包括 Linux、MacOS 和 Windows。在容器或虛擬機中運行您的工作流。

在決定是否值得改變之前，讓我們先了解誰應該考慮這一點。

你是否應該考慮從Jenkins中轉移出來？

如果你使用Jenkins一切都很順利，你對你的設置很有信心，同時擁有完全的控制權，成本也不是問題，我建議繼續使用Jenkins。

對于那些使用GitHub作為源碼控制平臺，并且已經覺得對自己的Jenkins設置沒有信心，尋求更好的替代方案的人來說，GitHub行動將成為首要考慮的選擇。

由于GitHub Actions是由GitHub完全管理的服務，因此您不需要知道如何擴展和操作基礎設施來運行它。

這是我選擇從Jenkins轉移出來的主要原因，在那里，我不能完全控制我的CI/CD管道發生了什么。

我不得不面對的一些挑戰：

• 保持插件最新。

• 即使我沒有運行任何構建，我的單個Jenkins服務器構建也要花錢。

• 在并發構建等方面不一致

• 我不得不依賴幾個插件，這些插件會出現更新，我需要時常處理。

我知道有Jenkins的解決方案可以解決其中的一些問題，但我已經受夠了，并轉向了托管平臺。

我希望我已經樹立了正確的心態，如果你適用于GitHub Actions，那么就可以轉到GitHub Actions。讓我們看看GitHub Actions提供的功能來考慮這一舉措。

易于設置——全部由GitHub管理

我認為，GitHub Actions在Jenkins之上的首要優勢是在GitHub Actions上的設置簡便性。GitHub Actions在云端運行，你也可以選擇在本地運行，這就是所謂的運行器。相反，Jenkins沒有提供官方的管理服務。

而且我可能不會去選擇任何第三方的Jenkin托管產品。我覺得把對源代碼和敏感信息的訪問權交給第三方供應商風險太大。

由于這個原因，Jenkins服務器需要安裝，而GitHub Actions不需要。因此，在GitHub Actions中，設置過程就方便多了。此外，GitHub Actions是一系列的docker運行。它僅需要 docker build 和 docker run ，這使得運行和調試非常容易。

與GitHub緊密集成——無縫體驗

最初，Jenkins似乎比GitHub Actions更靈活。Jenkins主要基于帳戶和觸發器，并以構建為中心。這些不符合GitHub events。與此相反，GitHub的actions涵蓋范圍很廣。因此，每個GitHub events都有一個GitHub Action。

GitHub Actions支持多種語言和框架，它們也使用YAML編寫。因此，它們可以像代碼一樣進行編輯，重用，共享和forked。

它與GitHub的使用很直接，因為當你forke一個倉庫時，動作會自動被forke。

這讓你可以非常高效地測試和構建項目，甚至可以在更接近開發者的地方運行項目。另外，您可以隨時訪問GitHub API，從而使其在開發人員中更受歡迎。

使用Bit（Github）時，可以看到這種緊密集成的一種流行用例。Bit是一個工具和平臺，它可以輕松地將JS組件（Node、React、Vue、Angular等）從任何資源庫共享到Bit的云服務，并從那里共享到其他資源庫。

Bit的云服務可以自動生成對所有Github倉庫的拉取請求，這些倉庫受一個共享組件的變更影響。這些自動生成的PR可以作為Github Actions的觸發器。

這意味著，對一個單一（共享）組件的改變可以在所有使用它的資源庫中傳播，觸發CI，驗證所有項目沒有被破壞。

GitHub Actions的另一大“特色”是，它們可以通過GitHub Marketplace相互分享。你可以重用其他開發者編寫的Action，這樣可以為你節省大量的時間，避免重寫已有的代碼。

協調器和構建節點——規?；瘶嫿?/h2>

GitHub Actions默認遵循主從（協調者和構建節點）模式，而不是Jenkins為我們提供的順序管道。

然而，需要注意的是，類似的設置在Jenkins中也是可以實現的，但需要額外的努力和知識才能讓它運行起來。

Jenkins	Github Actions
服務器需要安裝	無需安裝，因為它是在云端
任務或工作將是同步的，這將消耗更多的時間將產品部署到市場上	實現了異步CI/CD
基于賬戶和觸發器，以不符合Github事件的構建為中心	為每個Github事件提供動作，支持多種語言和框架
需要在Docker鏡像上運行，以保證環境的兼容性	適用于任何環境
有支持緩存機制的插件	如果你需要緩存，必須自己寫緩存機制
不具備共享的能力	可以通過Github Marketpalce分享

如果你使用Jenkins，默認設置將同步運行部署管道中的每一步。例如，如果你需要運行單元測試、集成測試和一些Sonar驗證，它們必須在一個服務器環境中運行。根據服務器中的可用資源，這可能會延遲執行。此外，您無需付出額外的努力來使管道可靠。

通過使用GitHub Actions，這些工作可以并行化，如上圖所示，例如，工作1可以是單元測試和集成測試，工作2可以是Sonar驗證。

總結

就其優勢而言，我們認真地研究了GitHub Actions領先于Jenkins的幾個領域。此外，GitHub Actions的增長速度比Jenkins快，成千上萬的GitHub Actions被發布到GitHub marketplace。圍繞這個社區也在不斷完善，其中有專門的GitHub Actions的倉庫。這意味著什么？

但是，是否在項目中使用GitHub Actions或Jenkins取決于您。目前，GitHub Actions對于公共倉庫是免費使用的。對于私有倉庫，它具有按需付費的機制。

我希望你已經意識到GitHub Actions是比Jenkins更有優勢的選擇，主要是因為它的靈活性。對于那些開始新項目或使用GitHub作為他們的源碼控制平臺的人來說，轉向GitHub Actions是個不錯的選擇。

首先，GitHub文檔提供了具體的實現步驟，GitHub Actions的工作流語法可以在這里找到。