在过去的几年中，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
翻译：张张
本文转载自微信公众号「前端全栈开发者」，可以通过以下二维码关注。转载本文请联系前端全栈开发者公众号。
