Github Actions還是Jenkins？該怎么選？
在過去的幾年中，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，這樣可以為你節省大量的時間，避免重寫已有的代碼。
協調器和構建節點——規模化構建
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是個不錯的選擇。
原文：https://blog.bitsrc.io/github-actions-or-jenkins-making-the-right-choice-for-you-9ac774684c8
翻譯：張張
本文轉載自微信公眾號「前端全棧開發者」，可以通過以下二維碼關注。轉載本文請聯系前端全棧開發者公眾號。
