在过去的几年中，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的处置打算可以处置其中的一些疑问，但我曾经受够了，并转向了托管平台。
我宿愿我曾经树立了正确的心态，假设你实用于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
和，这使得运转和调试十分容易。
与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中也是可以成功的，但须要额外的致力和常识才干让它运转起来。
| 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的上班流语法可以在这里找到。