Github Actions与Jenkins，该如何做出正确的选择？

在过去的几年中，DevOps已成为软件生命周期中至关重要的一部分。这推动了许多领先的DevOps工具和实践的增长。你可以找到一系列支持CI/CD流程的工具。Jenkins和GitHub Actions脱颖而出。

在本文中，我将GitHub Actions与Jenkins进行比较，并为你提供更深入的了解，从而让你做出正确的选择。

Jenkins和GitHub Action简介

让我们从Jenkins开始。下面是它的一个简短的描述：

Jenkins是一个免费的开源的自动化服务。

它有助于软件开发的自动化，特别是在构建，测试和部署相关部分，同时能够促进持续集成和持续交付。

——维基百科

同样，GitHub Actions是GitHub作为SaaS产品提供的两个产品中的最新的一个。

GitHub Actions现在使在任何平台（包括Linux，MacOS和Windows）上自动化构建，测试和部署项目变得更加容易。

在容器或虚拟机中运行你的工作流。

——来自GitHub博客

在决定是否值得迁移之前，让我们先了解一下谁应该优先考虑这一点。

你应该考虑从Jenkins迁移吗？

如果使用Jenkins能够满足你的所有工作需求，同时你对Jenkins相关的设置也了如指掌，并且成本也不是问题，那么我建议你继续使用Jenkins。

对于那些使用GitHub作为源代码控制平台，同时已经不能完全掌控Jenkins相关的设置，并寻求更好选择的人，GitHub Actions将成为主要的考虑选择。

由于GitHub Actions是GitHub的一个完全托管服务，所以你无需了解如何扩展和操作基础结构来运行它。

我从Jenkins迁移的主要原因是我已经无法完全掌控CI/CD管线了。

我必须应对的一些挑战。

保持插件最新。
即使我没有运行任何构建，我的单个Jenkins服务器构建也要花钱。
并发构建不一致。
几个必要插件的更新需要定时维护。

我知道针对这些问题，Jenkins也有解决方案，但是我受够了，所以转到了一个托管平台上。

我希望在迁移到GitHub Actions上面我树立了正确的思维方式。让我们从GitHub Actions提供的功能上面来考察这次迁移。

易于搭建——全部由GitHub托管

我认为，GitHub Actions在Jenkins之上的首要优势是其搭建的简便性。GitHub Actions运行在云端。你也可以选择在本地运行它，我们称其为运行者（runner）。相反，Jenkins没有官方提供的托管服务。

而且，我可能不会选择Jenkins的任何第三方托管产品。我觉得将对源代码和敏感信息的访问权交给第三方提供商的风险太大。

由于这个原因，Jenkins服务需要安装，而GitHub Actions则不需要。因此，GitHub Actions的设置过程非常方便。此外，GitHub Actions是一系列Docker运行。它仅需要docker build和docker run。这使得运行和调试非常容易。

与GitHub紧密集成——无缝体验

起初，Jenkins看上去比GitHub Actions更灵活。Jenkins主要基于帐户和触发器，并以构建为中心。这些和GitHub事件完全不一样。与此相反，GitHub Actions涵盖范围很广。因此，每个GitHub事件都有一个GitHub Action。

GitHub Actions支持多种语言和框架，它们也使用YAML编写。因此，它们可以像代码一样进行编辑，重用，共享和分叉。

与GitHub一起使用很简单，因为当你分叉仓库时，Actions也会自动被分叉过去。

这使你可以非常高效的测试和构建项目，甚至使它们更接近开发人员。此外，你可以随时访问GitHub API，从而使其在开发人员中更受欢迎。

当使用Bit[1]（Github[2]）时，你可以看到这种紧密集成的一个流行用例。Bit是一个工具和平台，它可以轻松地将JS组件（Node，React，Vue，Angular等）从任何仓库共享到Bit的云服务，也可以从Bit的云服务共享到其他仓库中。

当共享组件变更时，Bit的云服务可以自动生成对所有受影响的GitHub仓库的拉取请求。这些自动生成的PR可以用作Github Actions的触发器。

也就是说，对一个（共享）组件所做的变更会传播到所有使用它的仓库上，从而触发CI来验证所有项目是否受到影响。

共享在Bit.dev上的组件

在此处[3]阅读有关Bit <> Github集成的更多信息。

GitHub Actions的另一个重要“功能”是它们可以通过GitHub市场（Marketplace）[4]相互共享。你可以重用其他开发人员编写的Action，这样可以节省大量时间，并避免重写已经可用的代码。

协调器和构建节点——规模化构建

默认情况下，GitHub Actions遵循主从模式（协调器和构建节点），而不是Jenkins为我们提供的顺序管道。

不过，值得注意的是Jenkins也可以按照类似的模式搭建，但是这就需要花费额外的努力和知识才能搭建起来并运行。

多个GitHub Actions组件可以协同运行作业

如果使用Jenkins，则默认设置将同步运行部署管道中的每个步骤。例如，如果你需要运行单元测试，集成测试和某些Sonar验证，则它们必须在单个服务器环境中运行。根据服务器中的可用资源，这可能会延迟执行。此外，你无需付出额外的努力来使管道可靠。

通过使用GitHub Actions，这些都可以并行执行，如上图所示。例如，作业1可以是单元测试和集成测试，作业2可以是Sonar验证。

总结

就它们的优势而言，我们认真地研究了GitHub Actions优于Jenkins的一些领域。此外，GitHub Actions的增长速度比Jenkins快，数以千计的GitHub Actions被发布到了GitHub市场上。与此相关的社区也在不断改进，那里有用于GitHub Actions的专用仓库。这意味着什么？

群众喜爱它！

让我们看一下对比总结。

Jenkins	GitHub Actions
服务需要安装	部署在云上，不需要安装
任何或作业是同步运行的，会花费更多的时间部署产品	异步CI/CD
基于账户和触发器，并以构建为中心，和GitHub的事件完全不相同	为每个GitHub事件提供Action，并且支持多种语言和框架
需要运行环境兼容的Docker镜像	兼容任何环境
拥有支持缓存机制的插件	需要自己实现缓存机制
没有共享机制	可以通过GitHub市场实现共享

但是，是否在项目中使用GitHub Actions或Jenkins取决于你。目前，GitHub Actions可免费用于公共仓库。对于私有仓库，它具有按需付费的机制。

我希望你已经意识到GitHub Actions由于其灵活性，目前是优于Jenkins的一个主要选择。对于那些开始一个新项目或使用GitHub作为其源代码控制平台的人，可以毫不费力地转向GitHub Actions。

对于初学者，GitHub文[5]档提供了实现此目标的详细步骤。可以在此处[6]找到GitHub Actions的工作流语法。

希望你喜欢这篇文章。谢谢阅读！