GitHub上的CI/CD和自动化初学者指南

后端之巅
319 阅读11分钟

我第一次看到CI/CD管道的运作是一个真正的觉醒时刻。我当时在一家公司工作，该公司使用GitHub Actions将发布时间缩短到5分钟。如果出现任何问题，你可以通过触摸一个按钮来回滚发布。

当时，我刚刚结束了在一家创业公司的工作，那里的发布过程更多的是手工操作，也更让人焦虑。我们是一个小团队，没有CI/CD管道或蓝绿部署的好处，我们只能在用户不太可能在深夜使用我们的应用程序时发布更新。这是一个乏味的过程，任何程度的人为错误都会延长部署构建所需的时间。

然而，在GitHub Actions上运行的自动化工作流程的推动下，CI/CD的第一次经验将一个流行语变成了具体而令人印象深刻的东西。现在，有意思的是，我在GitHub工作，GitHub Actions已经成为我个人的重点领域。

因此，对于那些刚刚开始在GitHub上使用CI/CD和工作流自动化的人来说，我想把我被介绍给GitHub Actions的经历变成一种资源。

让我们开始吧。

专业提示：如果你想在不同的CI/CD和DevOps工具之间做出决定，请查看GitHub与其他平台的比较。

那么，GitHub Actions究竟是什么？

对于不熟悉的人或者听说过但不完全了解的人来说，GitHub Actions是一个原生的CI/CD工具，与你在GitHub中的代码一起运行。事实上，你可能已经注意到GitHub仓库中的一个标签，上面写着 "Actions"（提示：这就是GitHub Actions的所在）。

A screenshot showing the GitHub Actions tab in a repository

截图显示仓库中的 GitHub Actions 标签

一旦你第一次打开这个标签，你会发现一个关于 GitHub Actions 的快速描述，以及一些针对你的仓库的建议工作流程。这就是有趣的开始。GitHub Actions在GitHub市场上有超过13,000个预先编写和测试过的CI/CD工作流程和预建的自动程序，以及在易于使用的YAML文件中编写你自己的工作流程（或定制现有的工作流程）的能力。

开发者第一次在仓库中打开GitHub Actions时看到的介绍屏幕截图

我稍后会教你如何建立自己的 GitHub Actions 工作流，但现在我先把这个留给你。一个GitHub Actions工作流可以被设计为响应GitHub上的任何webhook事件。这意味着你可以把GitHub上的任何webhook变成CI/CD管道中自动化的触发器--这也包括第三方的webhook事件。

GitHub Actions 工作流程背后的概念

所以，我们已经谈了一些关于GitHub Actions的工作流程，但有时最简单的方法是看看它的运行情况（双关语）。

A screenshot of an example GitHub Actions workflow

一个GitHub Actions工作流程的例子的截图

上述工作流程是由几个不同的部分组成的。这些东西包括。

  • 运行器。跑步者是 GitHub Actions 的服务器。每个运行器可以由GitHub托管，也可以在本地化的服务器上自行托管。GitHub 托管的运行器基于 Ubuntu Linux、Windows 和 macOS，你可以在工作流程中指定。
  • 事件。事件是定义的触发器，用于启动工作流。
  • 工作。工作是一组在同一个运行器上执行的步骤。
  • 步骤。步骤是单独的任务，在工作中运行命令。这些可以是一个行动或一个shell命令。
  • 行动。行动是在运行器上执行的命令，也是 GitHub 行动的核心元素，它是以行动命名的。

当你把所有这些概念放在一起时，你会得到一个可能看起来像这样的工作流程。

on:
  issues:
    types: [opened]

jobs:
  comment:
    runs-on: ubuntu-latest
    steps:
     - name: Rick Roll
      uses: TejasvOnly/random-rickroll@v1.0
      with:
        percentage: 100

(作为参考，这是一个有趣的GitHub Actions工作流程，理论上你可以将其作为CI/CD管道的一部分。它将Rick Astley的GIF图片作为评论发布在仓库中打开的每一个新问题上，这被科学地证明可以提高你的工作效率和总体乐趣。我保证）。

**想了解更多吗？**看看这篇来自@mishmanners的 文章，它很好地解释了GitHub Actions工作流的所有组成部分之间的区别，包括 "行动 "和 "工作流 "之间的区别。

GitHub 动作的常见用例（以及为什么你应该关心）。

根据我的经验，我有四种使用GitHub Actions的常见方式（别担心，我包括了预建工作流程的链接，你可以把它放到你的仓库里并立即开始使用）。这些包括。

用于CI/CD的GitHub Actions工作流程

说到这里，你应该不会惊讶，GitHub Actions的一个强大而常见的用例就是围绕着CI/CD。

它远不是唯一的CI/CD平台（你可以将任何CI/CD平台整合到你的GitHub工作流程中），但它的优势在于它与GitHub平台的其他部分紧密结合--能够通过GitHub上的任何网络钩子来触发CI/CD管道的任何部分。

下面是一些有用的、预建的GitHub Actions CI/CD工作流程，你可以用来开始使用。

  • Node.js持续集成。这个工作流程将对node的依赖关系进行清洁安装，缓存并恢复它们，构建源代码，并在不同版本的node中运行测试，以帮助减少人为错误。虽然这是专门针对Node.js的，但也有其他工作流程适用于其他编程语言，而且都超级有用。
  • 在你的代码库上运行端到端的测试。无论你是利用Cypress、Applitools还是Mabl对你的应用程序进行端到端的UI测试，都有一个GitHub Actions工作流程。试着在你的仓库中加入这些GitHub Actions，在你将代码合并到生产中之前触发测试运行。
  • 部署容器镜像到亚马逊ECR：这个工作流将构建并推送一个新的容器镜像到亚马逊ECR，然后当有推送到你的默认分支时，将部署一个新的任务定义到亚马逊ECS。请记住，不同的平台也有类似的GitHub Actions，如Terraform和谷歌云平台。

用于发布管理的GitHub Actions工作流程

发布管理是CI/CD管道的一个关键部分。然而，即使没有完全出炉的CI/CD管道，你也可以将你的发布自动化。无论你选择哪种途径，这里有两个非常有用的GitHub Actions工作流程，可以提升你的发布管理方法。

  • 如果发生错误，回滚或删除发布。我们都经历过这种情况。我曾经发布过新的功能或错误修复，但却造成了更多的问题。有时，我甚至把生产版本删除了（这是有可能的）。如果你发现你的发布中有任何错误，这个动作可以让你轻松地启动回滚，这意味着节省时间，这样你就可以开始工作，修复你的构建中的任何问题。
  • **自动发布npm包：**当你推送代码到指定分支时，这个动作会自动发布你的npm包。这是一件看似简单的事情，但我保证它能在关键时刻为你节省时间。

用于第三方集成的GitHub动作工作流程

无论我们谈论的是你的CI/CD管道的一部分，还是你正常工作流程的一部分，你在构建代码时很有可能使用不止一个工具。确保所有这些工具相互集成可能是开发工作中不太有趣的部分之一，但这是一个重要的步骤。

这里有两类工作流程，我觉得对任何初学者都特别有帮助。

  • 向Slack发送通知。这个动作对于在你经常使用的通信工具中保持更新是很有用的（如果你使用微软团队，也有一个动作用于此）。你可以用这个动作来通知你关于发布、构建失败、CI/CD过程、新打开的拉动请求等等。
  • 将你的项目计划板与你的资源库连接起来。无论你使用的是Jira、Trello还是GitHub Issues，你都可以利用一些GitHub Actions的工作流程，将它们与你的项目结合起来。这意味着你可以在构建失败或成功时自动触发新的问题和问题的评论，测试也是如此。这对我个人来说，可以通过自动更新我的项目规划板来帮助我跟踪哪些工作，哪些不工作。

用于社区和团队管理的GitHub Actions工作流程

当我与开源维护者和公司的人交谈时，我一再听到维护一个活跃的项目、团队和/或社区是多么的耗时。除了CI/CD，GitHub Actions也是一个很好的工具，可以将组织内可重复的、但往往是手动的任务自动化，以及大规模地管理项目和团队。

本着这种精神，下面是我遇到的几个有用的GitHub Actions工作流程。

  • 采取行动。这个简单的工作流程使项目中的贡献者或团队成员能够将自己分配给问题。它还可以被配置为对问题进行评论，并预装内容，可以解释项目的技术并提供指导，或者只是感谢某人承担了问题。
  • 首次互动。这个工作流欢迎第一次来到你的版本库的贡献者，你可以自己设置一个预载的信息。这是一个很好的方式来接纳新的团队成员和贡献者，并确保每个人在贡献项目之前对项目有一个基本的了解。
  • 邀请我：它可能对开源社区更有用，但我个人喜欢这个工作流程。如果合作者对某一问题发表评论，它就会邀请合作者加入一个公共组织--这让合作者有责任接收并接受邀请。

预先建立的启动工作流程，你可以立即添加到你的资源库中去

如果上述工作流程还不足以让你忙碌，我想再给你一些。在我们的入门工作流程库中，你可以找到一堆预建的GitHub动作，可以随时用于持续集成、持续部署、代码扫描和工作流程自动化。每一个工作流程都是由GitHub团队建立和测试的，而且还定期更新。

我个人最喜欢的是**CodeQL**，它将GitHub的静态代码分析引擎引入你的工作流程，以识别代码中的任何已知安全漏洞。此外，还有很多其他预建的工作流程，适用于你可能正在做的任何事情。

以下是如何开始使用其中一个预建的启动工作流程。

  1. 在你的资源库中创建一个 .github/workflows 文件夹。
  2. 在该文件夹中创建一个.yml文件。
  3. 复制并粘贴预建工作流程的内容到你的.yml文件。
  4. 根据需要定制该文件。
  5. 触发动作，测试它是否成功运行。

专业提示：自定义预建的 GitHub 动作工作流程以适应你的需要

由于GitHub市场上有超过13,000个GitHub动作，你很有可能不需要从头开始创建一个工作流程，因为可能已经有一个了。然而，有几次你可能会发现一个几乎完美的工作流程，但需要稍作调整才能完全满足你的需求。

在这种情况下，你可以创建一个新的工作流程，或者定制一个预先建立的工作流程。如果你想知道如何定制一个工作流程，请尝试阅读我整理的这篇文章。

了解如何定制预先建立的GitHub Actions工作流程

学习如何建立自己的GitHub Actions工作流程

有时候，看别人实时做某件事情会更容易学习。所以，如果你想建立自己的GitHub Actions工作流程，请看这个视频，学习如何在10分钟内建立自己的动作。

<！--[if lt IE 9]>document.createElement('video'); github.blog/wp-content/…

其他资源

avatar
文章
阅读
粉丝