概览

清单团队有一些激动人心的更新准备发布到注册表中，但他们在发布到生产环境之前，需要对这些模式更改充满信心变体. 幸运的是，有一个 GraphOS 功能可以帮助实现： 模式检查！

在本课中，我们将

• 了解不同类型的 模式检查
• 了解 模式检查 如何融入更新 超图 的整体流程中
• 了解 发布流程 GraphOS

在本课程中，我们主要关注流程的概览。下一课将深入探讨如何运行每个检查的详情。

什么是架构检查？

架构检查是帮助确定由架构更新造成的潜在故障的一组预定义测试。它们会检查不兼容的 子图架构或破坏现有客户端 操作等问题。利用架构检查，我们能确保在实施到产品环境的时候架构更改不会导致问题。

我们有三种类型的架构检查：构建检查、操作检查和 linter 检查。

构建检查

构建检查验证一个子图的架构更改仍能够与超图中的其他子图架构良好组合。

例如，如果一个 子图添加了新类型，则构建检查将确定该添加与 超图的其余子图是否兼容。如果不兼容，我们需要调查错误并予以修复。

操作检查

操作检查验证架构更改不会破坏现有客户端发送给图的任何操作。

例如，假设一个网络客户端定期发送 GraphQL查询 以检索其主页的数据。如果架构更改涉及向 需要的参数 添加一个 字段 在该 查询 中，如果它不包括该参数，它可能会损坏该客户端现有的 操作！操作检查有助于我们保护自身免受此潜在故障的影响，列出受影响的操作并允许团队解决这些操作。

解析器检查

解析器检查分析您提议的架构更改是否违反格式化规则和其他 GraphQL 最佳实践。 GraphOS 提供了一组默认规则，您可以对其进行配置以适应您的团队约定。您可以在 Apollo 文档 中看到规则的完整列表。

一些常见的架构约定包括：以 字段 名称书写 camelCase，以 PascalCase 书写类型名称，以 SCREAMING_SNAKE_CASE 书写枚举。

如何运行架构检查

有两种主要方法可以使用 Rover CLI 运行 架构检查。我们可以在终端中本地运行架构检查。我们还可以将架构检查集成到 CI 管道中，以便针对新的拉取请求自动运行。

要对 子图 执行架构检查，我们使用 rover subgraph check 命令，并带有以下参数：

此命令先运行构建检查，然后进行 操作 检查，然后进行 linter 检查，最后输出命令行中的结果。还会向 GraphOS 报告结果，以便我们可以查看图表的检查页面中的结果。

超图故事中的架构检查

让我们重新审视一下我们的故事，放大到 架构检查 发生的位置以及它们失败、通过或被主动覆盖时会发生什么。

在对 子图架构（无论是添加、移除还是更新定义）进行更改之后，我们首先想要使用 Rover 从本地运行 架构检查 。

首先，Rover将验证子图的架构更改是否仍能与超图中的其他子图架构成功组合。默认情况下，此检查针对current 变种的图表运行，但我们还可以在 Studio 中选择任何已注册的图表变种。

如果构建检查成功，Rover会在之后立即运行一个操作检查。这将验证架构的更改不会中断现有客户端发送到图表的任何操作。

如果其中一项检查失败，Rover会提供一个指向 Studio检查页面的链接，其中包含有关错误详情的更多信息。

如果所有检查都成功，我们可以继续按照之前的流程进行操作：我们会使用Rover将子图架构发布到注册表。

当我们对发布架构更改感兴趣时，让我们花点时间了解GraphOS的一个有用功能：启动。

启动进程

通过发布到架构注册表，我们在GraphOS中触发了一个启动。

启动表示对任何图表的变体进行架构更新的整个过程.

启动以GraphOS尝试组合supergraph开始. 如果它失败, 那么我们将看到错误并且过程会在此结束. 否则, 将生成supergraph 架构. 超图架构提供给上行链路, GraphOS 路由器将获取最新的架构.

我们已经成功完成对图表的架构更新!

那就是架构检查和启动过程在我们超图中的样子.

实践

要点

• 模式检查有助于在模式更新可能导致生产问题之前识别潜在故障。
• 构建检查验证子图的模式更改仍可以与其他子图模式成功合成。
• 操作检查验证模式的更改不会中断现有客户端向图发送的任何操作。
• Linter 检查验证模式是否遵循格式化规则和惯例。
• 要运行模式检查，我们使用rover subgraph check命令。
• 我们可以通过终端或 Studio 检查页面查看模式检查的结果。
• 一个启动表示为任何变体的图进行模式更新的完整过程。它由子图发布到模式注册表时触发。

接下来

在接下来的三节课中，我们将了解模式检查在我们的开发工作流中的工作方式，以及如何在 CI/CD 过程中实现自动化。