Github Actions还是Jenkins？该怎么选？-轻识

原文：https://blog.bitsrc.io/github-actions-or-jenkins-making-the-right-choice-for-you-9ac774684c8
翻译：张张

在过去的几年中，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是个不错的选择。

最后

如果你觉得这篇内容对你挺有启发，我想邀请你帮我三个小忙：

点个「在看」，让更多的人也能看到这篇内容（喜欢不点在看，都是耍流氓 -_-）
欢迎加我微信「qianyu443033099」拉你进技术群，长期交流学习...
关注公众号「前端下午茶」，持续为你推送精选好文，也可以加我为好友，随时聊骚。

点个在看支持我吧，转发就更好了