概述
我们来获取这些架构检查并发布集成到我们的自动化工具中,这样我们就不必在每次想要进行更改时记住何时以及如何运行它们了。
在本课程中,我们将
- 创建用于 架构检查和发布的 CI/CD 管道使用 Rover和 GitHub Actions
完整的架构交付过程
在我们深入研究如何设置 CI/CD 管道之前,让我们退后一步,看看整个过程,包括 架构检查和 启动,以及它们在我们开发周期中的位置。
我们希望将模式检查设置成当拉取请求中的代码更改时可以自动运行。通过这种方式,在成功合并每个 PR 之前,它都将检查该模式是否仍然可用且各项检查是否通过。我们可以在知道我们的模式更改不会破坏我们的超图或现有客户端查询的情况下,放心地合并。
首先,我们将做出模式和代码更改,并在本地运行模式检查。如果一切正常,我们将创建一个拉取请求,该请求将触发 GitHub 工作流以运行模式检查(我们将创建此工作流!)。
如果检查失败,我们将看到 GitHub PR 中的错误,该错误还将链接到 Studio 以获取更多详细信息。我们需要调查错误,在我们的本地环境中修复错误,然后从头开始再次遵循流程。
如果检查通过,太好了!我们可以将更改合并到main
分支。Railway 将自动收到有关这些更改的通知并部署最新版本。(或者,如果您不使用 Railway,您可以添加不同的 GitHub 工作流,以将main
分支部署到您选择的平台!)
接下来,我们需要设置另一个 GitHub 工作流以自动化发行架构。在确认部署成功后,我们将手动触发此工作流。我们将遵循 启动在 Studio 中进行处理,直到在每个地方看到绿色对勾为止!
哦,真是激动人心!即使你只是一位正在尝试学习教程的开发人员,这似乎也需要很多设置和操作。但是当你准备升级并确保为安全可靠 超图 演变做好基础时,我们希望这些工作流能有所帮助!
注意:GitHub Actions是我们用来自动化 CI/CD 工作流的方式。这些工作流可以由事件触发,例如创建或关闭请求、分支上的新提交,甚至可以通过按按钮手动触发。
探索 GitHub Actions
当 Railway 为你克隆存储库时,它还会从原始存储库中带来工作流。你自己不需要编码工作流!
可以在操作在你的 repo 中找到它们。
架构检查工作流
从左侧边栏中的列表中选择 “架构检查” 工作流,然后点击文件名 (check-schema.yaml
) 检查该文件的内容。
不用过于纠结这些工作流程的具体语法。我们在文件中留下了注释来帮助你理解正在发生的事情,本课程的目标更多是让你对所有部署部分如何组合在一起有一个大局观。注意 步骤:
部分,其中概述了为此作业运行哪些命令。
我们已定义此工作流程应在每次拉取请求打开、更新、编辑时运行。
在最后,它运行我们熟悉的 rover 子图检查
命令。我们需要向其提供 变量它期待的 APOLLO_GRAPH_REF
和 APOLLO_SUBGRAPH_NAME
。我们将在下一部分中设置它们。
注意:理想情况下,如果模式检查工作流程失败,你将希望防止合并到 main
中。你可以在 GitHub 文档 中了解有关必需状态检查和分支保护规则的更多信息。
发布模式
返回 操作 选项卡,从左侧边栏中的列表中选择“发布模式”工作流程,然后单击文件名 (publish-schema.yaml
) 以查看文件内容。
我们已定义该工作流应手动运行。
在最后,它运行 rover 子图发布
命令。与前一个工作流一样,我们需要为其提供 变量,使其符合预期。让我们进行设置。
设置变量
在 GitHub 中,导航到 设置选项卡。
单击 秘密和变量,然后单击 操作。这是所有秘密和 变量 及我们所需工作流存在的区域。秘密用于敏感数据,而变量用于非敏感数据。
https://github.com
首先,我们来处理 变量。工作流需要两件事:图引用 (APOLLO_GRAPH_REF
) 和 子图 名称 (APOLLO_SUBGRAPH_NAME
)。
注意:我们将 变量 名称的前缀设置为 APOLLO_
,以使其与应用程序中可能拥有的其他 变量 区分开来。
单击 变量选项卡,然后单击 新存储库变量。
https://github.com在 名称 输入中添加
APOLLO_GRAPH_REF
。在 值 输入中,粘贴你的 图引用。请记住,我们可以在 Studio 中找到此值,位于图表的自述文件页面的顶部。
点击 添加变量。
为 APOLLO_SUBGRAPH_NAME 添加另一个
variable
,将其设置为recipes
,这是我们的 subgraph 名称。https://github.com
完美! 变量准备就绪,接下来是 APOLLO_KEY
密钥。
设置 APOLLO_KEY
密钥
这将成为 API 密钥,用于告知 GraphOS我们被允许对此特定 supergraph 进行更改。这是一项重要密钥,应该保密。这是一项敏感数据,我们不希望任何其他人拥有,因为他们能够对我们的 supergraph 进行更改!
单击 机密选项卡,然后单击 新建存储库机密。
https://github.com将 名称设置为
APOLLO_KEY
。
如果你还记得在课程开始时我们设置 Rover 时,我们使用 rover config auth
并向其提供了 个人 API 密钥。个人 API 密钥适用于本地开发,例如在本地终端中运行命令。
对于 CI/CD 目的,我们需要使用 图表 API 密钥。 我们希望为与 GraphOS 通信的每个非开发系统创建唯一的 图表 API 密钥。通过这样做,我们可以更好地控制(并撤销)对我们的 supergraph 的访问权限。
让我们稍作改动,获取我们的 图表 API 密钥。
在 Studio 中,打开 超图的 设置页面,从 此 Relations选项卡中选择 API 密钥选项。
单击 创建新密钥. 为您的密钥命名,如 “GitHub PR”。
https://github.com复制密钥(您将无法再次看到它!)。
将其粘贴到 GitHub 机密值中。
单击 添加机密保存您的更改。
https://github.com
大功告成!🥳 我们已设置两个工作流程来帮助我们自动化架构交付流程。
- 在每次提出拉取请求、更新和编辑时运行的架构检查工作流程。
- 一旦我们的服务器部署成功,我们将手动触发发布架构工作流程。
干的好!您是否渴望看到这些工作流程发挥作用?那就继续吧。
练习
关键要点
- 我们可以轻松地集成 架构检查并将其发布到我们的 CI/CD 管道中,以便在对 超图进行更改时更安心。
- 为 CI/CD 目的使用图像 API 密钥. 您应为每个与 GraphOS通信的非开发系统创建一个唯一的图表 API 密钥,以便更好地控制(并撤消)谁有权访问您的 超图. 这些密钥应保密。
接下来
我们还没有完全完成弃用我们的 text
字段!请记住,我们仍在等待,以确保该字段的使用率降至零,以便我们能够安全地将其删除。在下一课中,我们将了解如何使用 GraphOS 字段见解来执行此操作,然后了解这些工作流的实际应用!
分享你对本课的疑问和评论
本课程目前进展情况
你需要一个 GitHub 帐号,才能在下方发帖。没有 GitHub 帐号? 改在我们的 Odyssey 论坛上发帖。