摘要：长期以来，持续集成/持续交付（CI/CD）一直是 DevOps 专家的工作领域。但随着 GitHub 在 2019 年通过 GitHub Actions 将原生 CI/CD 引入 GitHub，将 CI/CD 直接从您的版本库引入工作流程将比以往任何时候都更

长期以来，持续集成/持续交付（CI/CD）一直是 DevOps 专家的工作领域。但随着 GitHub 在 2019 年通过 GitHub Actions 将原生 CI/CD 引入 GitHub，将 CI/CD 直接从您的版本库引入工作流程将比以往任何时候都更加容易。这是一件大好事。作为开发人员，我们接受过使用同行评审来确保代码正常运行的培训。但我要告诉你，我们需要打破同行评审。如果你正在使用 Git、GitHub 和 GitHub Actions 构建 CI/CD 管道，你就应该对自己的代码有信心。我将教你如何从 GitHub 上的仓库构建自己的 CI/CD 管道。
首先，让我们谈一谈使用 GitHub Actions 的一些好处 — 因为实话实说，市面上有很多其他工具。让我来解读我发现的四大优势：

简单的 CI/CD 流水线设置：GitHub Actions 是由开发人员为开发人员开发的，因此您无需专门的资源来设置和维护您的流水线。无需手动配置和设置 CI/CD。您不必设置 Webhook，也不必购买硬件、预留一些实例，保持它们更新，进行安全补丁或关闭空闲机器。您只需在存储库中放入一个文件，就可以运行。响应 GitHub 上的任何 Webhook：由于 GitHub Actions 与 GitHub 完全集成，您可以将任何 Webhook 设置为触发自动化或 CI/CD 流水线的事件触发器。这包括拉取请求、问题和评论等内容，但也包括来自您已集成到 GitHub 存储库中的任何应用的 Webhook。假设您要使用市面上的许多工具之一来运行您的开发流水线的一部分。使用 GitHub Actions，您可以触发这些应用程序的 Webhook 的 CI/CD 工作流和流水线（甚至是一些简单的东西，比如聊天应用消息，如果您已将聊天应用集成到 GitHub 存储库中）。社区驱动，可重复使用的工作流：您可以将您的工作流公开共享给更广泛的 GitHub 社区，或在 GitHub Marketplace 中访问预构建的 CI/CD 工作流（这里有超过 11,000 个可用的操作！）。我有提到每个操作都可以通过引用其名称来重复使用吗？是的，也是。支持任何平台、任何语言和任何云：GitHub Actions 是平台无关的、语言无关的和云无关的。这意味着您可以与您选择的任何技术一起使用它。

在我们深入讨论之前，这里有一些快速提示：

要清楚 CI/CD 流水线是什么以及应该做什么。这是一个简单但重要的说明。CI 流水线在代码更改时运行，并应确保所有更改与集成的其余代码配合工作。它还应该编译您的代码，运行测试，并检查其是否正常运行。CD 流水线则进一步部署构建好的代码到生产环境中。
GitHub Actions 采用了“选择您自己的冒险”方式来处理 CI/CD。当您首次在存储库中打开 GitHub Actions 时，您会看到这一点。有许多预构建的 CI 工作流选项，您可以根据您的技术需求来利用。但如果您愿意，也可以从头开始构建自己的 CI 工作流。

我们的示例展示了一个基于 Astro 构建并通过 GitHub Pages 部署的网站。在本指南的 CI 和 CD 部分中，我们将使用我建立和开发的一个名为 www.opensauced.pizza 的网站。该网站旨在帮助首次开源贡献者更容易地找到要参与的开源项目，并优先考虑具有清晰入门流程的项目。

这可能听起来很基础，但使用 GitHub Actions 构建 CI 流水线的第一步是在 GitHub 上创建或选择一个存储库。您可以使用现有项目的代码库，从 GitHub 上喜欢的项目中派生一个项目，或者从头开始。

为了简单起见，我将在我的 Open Sauced 项目中使用 Open Sauced 存储库。请随意进一步查看该存储库，派生这个存储库并通过派生贡献。
GitHub - open-sauced/open-sauced: This is a project to identify your next open source contribution.

您可以看到，Open Sauced 存储库相对简单。网站本身是使用 OneGraph 制作的，托管在 Netlify 上，并使用 HTML、CSS 和 JavaScript 构建。我还利用 Storybook 进行 UI 和设计工作。我们还使用 React 和 npm 进行包管理、安装和测试 — 但稍后会详细介绍。

步骤 2：在您的存储库中打开 GitHub Actions，开始构建您的 CI/CD 工作流
要开始构建您的 CI/CD 流水线，请在存储库顶部导航栏中打开 GitHub Actions 选项卡。您将看到一系列与您的项目使用的技术相匹配的 CI/CD 和工作流自动化模板。

对于这个项目，我们将利用几种不同的 CI/CD 工作流来测试、构建、部署我们的代码。这些包括：

开发工作流：该工作流在每次打开、编辑、同步或重新打开拉取请求时运行一系列不同的作业。这些作业包括设置 Node、安装 npm 包和依赖项、运行 npm test，并通过多个 lint 作业（设置 node、安装 npm@latest、安装依赖项、lint 代码... 您明白我的意思）。
有关 YAML 的说明

YAML 是一种标记语言，由于其与 JSON 超集的人性化特性而成为声明性自动化的主要工具（与其他 JSON 标记语言变体相比，它使用的括号、大括号和引号要少得多）。想要了解更多？查看这个指南。

CodeQL 分析工作流：这个工作流在我们将代码合并到主分支后对我们的代码运行一系列 CodeQL 安全测试，以确保没有已知的漏洞。查看 YAML 文件。它非常简单，但有效，我强烈推荐使用。
发布和构建工作流：这个工作流在将代码更改发布到 Docker 并构建应用程序后运行测试并强制执行 lint。它还将最终代码部署到我们的生产环境中，使用类似自动发布说明的结构切一个发布，将站点打包成一个容器并发布到 ghcr。然后，它会在存储库中增加版本号和标签。这是我们运行的较复杂的工作流之一，我有点过于简化了，但您可以查看工作流中发生的作业和步骤。

storybook 部署工作流：该工作流通过前端 UI 技术 Storybook 将任何 UI 组件更改部署到我们的生产网站。

这些就是我们的工作流程。重点是，如果您正在做一个独立项目或一些小项目，构建一个 CI 流水线不必是一件令人畏惧的过程。您可以从几个简单的事情开始（就像上面突出的内容）来使您的工作流程变得更容易。

如果您正在构建企业软件、维护一个大型开源项目或在各种事务中与大团队合作，那么 CI/CD 流水线可以并且应该比这个更复杂。但如果您刚开始，不要担心使您的 CI/CD 流水线满足大团队或雄心勃勃项目的每一个需求 — 只需使其适应您即可。

您可以看到，我已经构建了一些工作流自动化，简化了维护 Open Sauced 存储库的过程。例如：Compliance 工作流程（来自 GitHub 用户 @mtfoley），每当有人在 Open Sauced 上进行首次拉取请求（符合我们的贡献者指南）时触发，并发送消息邀请他们加入我们的 Discord 服务器。

步骤 3：对您的代码进行更改，触发您的 CI/CD 流水线
为了进行这个练习，我们将对网站标题进行小改动（“通往下一个开源贡献之路”），在末尾添加“和更多的披萨”。最终结果将是：“通往下一个开源贡献之路和更多的披萨”。