6. 集成到 CI/CD 中
5m

概述

我们来获取这些并发布集成到我们的自动化工具中,这样我们就不必在每次想要进行更改时记住何时以及如何运行它们了。

在本课程中,我们将

  • 创建用于 和发布的 CI/CD 管道使用 和 GitHub Actions

完整的架构交付过程

在我们深入研究如何设置 CI/CD 管道之前,让我们退后一步,看看整个过程,包括 ,以及它们在我们开发周期中的位置。

我们希望将设置成当拉取请求中的代码更改时可以自动运行。通过这种方式,在成功合并每个 PR 之前,它都将检查该模式是否仍然可用且各项检查是否通过。我们可以在知道我们的模式更改不会破坏我们的或现有客户端查询的情况下,放心地合并。

首先,我们将做出模式和代码更改,并在本地运行模式检查。如果一切正常,我们将创建一个拉取请求,该请求将触发 GitHub 工作流以运行(我们将创建此工作流!)。

如果检查失败,我们将看到 GitHub PR 中的错误,该错误还将链接到 Studio 以获取更多详细信息。我们需要调查错误,在我们的本地环境中修复错误,然后从头开始再次遵循流程。

如果检查通过,太好了!我们可以将更改合并到main分支。Railway 将自动收到有关这些更改的通知并部署最新版本。(或者,如果您不使用 Railway,您可以添加不同的 GitHub 工作流,以将main分支部署到您选择的平台!)

CI Workflow, see expanded image description below

接下来,我们需要设置另一个 GitHub 工作流以自动化发行架构。在确认部署成功后,我们将手动触发此工作流。我们将遵循 在 Studio 中进行处理,直到在每个地方看到绿色对勾为止!

CD Workflow, see expanded image description below

哦,真是激动人心!即使你只是一位正在尝试学习教程的开发人员,这似乎也需要很多设置和操作。但是当你准备升级并确保为安全可靠 演变做好基础时,我们希望这些工作流能有所帮助!

注意:GitHub Actions是我们用来自动化 CI/CD 工作流的方式。这些工作流可以由事件触发,例如创建或关闭请求、分支上的新提交,甚至可以通过按按钮手动触发。

探索 GitHub Actions

当 Railway 为你克隆存储库时,它还会从原始存储库中带来工作流。你自己不需要编码工作流!

可以在操作在你的 repo 中找到它们。

架构检查工作流

从左侧边栏中的列表中选择 “工作流,然后点击文件名 (check-schema.yaml) 检查该文件的内容。

https://github.com

GitHub Schema checks workflow

不用过于纠结这些工作流程的具体语法。我们在文件中留下了注释来帮助你理解正在发生的事情,本课程的目标更多是让你对所有部署部分如何组合在一起有一个大局观。注意 步骤: 部分,其中概述了为此作业运行哪些命令。

我们已定义此工作流程应在每次拉取请求打开、更新、编辑时运行。

在最后,它运行我们熟悉的 rover 子图检查 命令。我们需要向其提供 它期待的 APOLLO_GRAPH_REFAPOLLO_SUBGRAPH_NAME。我们将在下一部分中设置它们。

注意:理想情况下,如果模式检查工作流程失败,你将希望防止合并到 main 中。你可以在 GitHub 文档 中了解有关必需状态检查和分支保护规则的更多信息。

发布模式

返回 操作 选项卡,从左侧边栏中的列表中选择“发布模式”工作流程,然后单击文件名 (publish-schema.yaml) 以查看文件内容。

https://github.com

GitHub Publish schema workflow

我们已定义该工作流应手动运行。

在最后,它运行 rover 子图发布 命令。与前一个工作流一样,我们需要为其提供 ,使其符合预期。让我们进行设置。

设置变量

  1. 在 GitHub 中,导航到 设置选项卡。

  2. 单击 秘密和变量,然后单击 操作。这是所有秘密和 及我们所需工作流存在的区域。秘密用于敏感数据,而变量用于非敏感数据。

    https://github.com

    GitHub Actions - secrets and variables

首先,我们来处理 。工作流需要两件事: (APOLLO_GRAPH_REF) 和 名称 (APOLLO_SUBGRAPH_NAME)。

注意:我们将 名称的前缀设置为 APOLLO_,以使其与应用程序中可能拥有的其他 区分开来。

  1. 单击 变量选项卡,然后单击 新存储库变量

    https://github.com

    GitHub Actions - Variables - new repository variable

  2. 名称 输入中添加 APOLLO_GRAPH_REF

  3. 输入中,粘贴你的 。请记住,我们可以在 Studio 中找到此值,位于图表的自述文件页面的顶部。

  4. 点击 添加变量

  5. 添加另一个 variable,将其设置为 recipes,这是我们的 名称。

    https://github.com

    GitHub variables successfully added

完美! 准备就绪,接下来是 APOLLO_KEY 密钥。

设置 APOLLO_KEY 密钥

这将成为 API 密钥,用于告知 我们被允许对此特定 进行更改。这是一项重要密钥,应该保密。这是一项敏感数据,我们不希望任何其他人拥有,因为他们能够对我们的 supergraph 进行更改!

  1. 单击 机密选项卡,然后单击 新建存储库机密

    https://github.com

    GitHub Actions - secrets and variables

  2. 名称设置为 APOLLO_KEY

如果你还记得在课程开始时我们设置 时,我们使用 rover config auth 并向其提供了 。个人 API 密钥适用于本地开发,例如在本地终端中运行命令。

对于 CI/CD 目的,我们需要使用 图表 API 密钥。 我们希望为与 通信的每个非开发系统创建唯一的 。通过这样做,我们可以更好地控制(并撤销)对我们的 的访问权限。

让我们稍作改动,获取我们的

  1. 在 Studio 中,打开 设置页面,从 此 Relations选项卡中选择 API 密钥选项。

  2. 单击 创建新密钥. 为您的密钥命名,如 “GitHub PR”。

    https://github.com

    Graph API Key generated in Studio

  3. 复制密钥(您将无法再次看到它!)。

  4. 将其粘贴到 GitHub 机密值中。

  5. 单击 添加机密保存您的更改。

    https://github.com

    GitHub secret successfully added

大功告成!🥳 我们已设置两个工作流程来帮助我们自动化架构交付流程。

  • 在每次提出拉取请求、更新和编辑时运行的架构检查工作流程。
  • 一旦我们的服务器部署成功,我们将手动触发发布架构工作流程。

干的好!您是否渴望看到这些工作流程发挥作用?那就继续吧。

练习

将架构检查添加到 CI 管道中有哪些好处?

关键要点

  • 我们可以轻松地集成 并将其发布到我们的 CI/CD 管道中,以便在对 进行更改时更安心。
  • 为 CI/CD 目的. 您应为每个与 通信的非开发系统创建一个唯一的图表 API 密钥,以便更好地控制(并撤消)谁有权访问您的 . 这些密钥应保密。

接下来

我们还没有完全完成弃用我们的 text !请记住,我们仍在等待,以确保该字段的使用率降至零,以便我们能够安全地将其删除。在下一课中,我们将了解如何使用 字段见解来执行此操作,然后了解这些工作流的实际应用!

上一步

分享你对本课的疑问和评论

本课程目前进展情况

beta
.你的反馈有助于我们进步!如果你遇到困难或困惑,请告诉我们,我们会提供帮助。所有评论都是公开的,并且必须遵守 Apollo 行为准则。请注意,已解决或已处理的评论可能会被删除。

你需要一个 GitHub 帐号,才能在下方发帖。没有 GitHub 帐号? 改在我们的 Odyssey 论坛上发帖。