概述
我们已经看到了我们的 超图 组成 本地，并且我们的更改已准备好进入下一阶段。我们 可以 只将更新后的模式发布到 GraphOS (我们在 两者 listings 和 reviews) ，但让我们暂停一下，首先验证这些更改不会破坏任何东西。毕竟，我们是负责任的开发人员！
在本课中，我们将
- 了解 模式检查 的类型
- 理解 模式检查 如何适应更新 超图 的整体过程
- 使用 Rover CLI 在本地运行模式检查
- 在 Studio 中检查模式检查的结果
什么是模式检查？
模式检查 是一组预定义的测试，有助于识别由模式更新引起的潜在故障。它们检查诸如 子图模式 之间的兼容性问题或破坏现有客户端 操作。使用 模式检查，我们可以确保我们的模式更改在部署到生产环境时不会导致问题。
我们将讨论三种 模式检查：构建检查、操作 检查和代码检查。
构建检查
构建检查 验证 子图 的模式更改是否仍然可以与 超图 中的其他 子图模式 成功地组合。
例如，如果将新类型添加到一个 子图，构建检查将确定该添加是否与 超图 中的其余子图兼容。如果不是，我们需要调查错误并修复它。
操作检查
操作检查 验证模式更改是否不会破坏现有客户端发送到 图 的任何 操作。
例如，假设一个 Web 客户端定期发送 GraphQL 查询 来检索其主页的数据。如果模式更改涉及在该 查询 中的 字段 中添加一个 必需 的 参数，它可能会破坏该客户端的现有 操作，如果它不包含该参数！操作检查有助于我们防止这种潜在的故障，列出受影响的操作并允许团队解决它们。
代码检查
代码检查 分析您的提议的模式更改，以查找格式规则和 GraphQL 最佳实践的违规行为。 GraphOS 提供了一组您可以配置以适应团队约定的默认规则。您可以在 Apollo 文档中查看规则的完整列表。
一些常见的模式约定包括：以 字段 名称为 camelCase、类型名称为 PascalCase 以及枚举类型为 SCREAMING_SNAKE_CASE。
使用 Rover 运行检查
我们可以使用 Rover 直接从命令行运行这些检查。Rover 会评估我们本地的更改，看看它们将如何影响我们已经投入生产的内容。它的输出将告诉我们一切我们需要了解的内容 - 以及我们需要修复的内容！- 在发布更改之前。
运行模式检查：rover subgraph check
要对 子图 执行模式检查，我们使用 rover subgraph check 命令，并带有以下参数：
rover subgraph check <APOLLO_GRAPH_REF> \--schema <SCHEMA_FILE_PATH> \--name <SUBGRAPH_NAME>
此命令运行 模式检查，然后将结果报告到 Studio，这样我们就可以从 图 的 检查 页面查看它们。
对 reviews 运行检查
让我们先检查 reviews 中的更改 子图。
在 reviews 目录中打开一个新的终端，并粘贴 rover subgraph check 命令。确保您将参数替换为 您 自己的值。
rover subgraph check <APOLLO_GRAPH_REF> \--schema src/main/resources/schema/schema.graphqls \--name reviews
该过程完成后，我们可以看到模式更改的报告。终端输出显示以下内容
该过程完成后，我们可以看到模式更改的报告。终端输出显示以下内容
Checking the proposed schema for subgraph reviews against Airlock@currenterror[E029]: Encountered 1 build error while trying to build subgraph "reviews"into supergraph "Airlock@current".Caused by:INVALID_FIELD_SHARING: Non-shareable field "Listing.id" is resolvedfrom multiple subgraphs: it is resolved from subgraphs "listings" and "reviews"and defined as non-shareable in subgraph "listings"The changes in the schema you proposed for subgraph reviews are incompatiblewith supergraph Airlock@current. See https://apollo.graphql.net.cn/docs/federation/errors/for more information on resolving build errors.
那么，这个 INVALID_FIELD_SHARING 错误是什么呢？嗯，reviews 子图 声明 Listing 作为一个 实体，但据我们所知，listings 子图 并没有！而且，Listing 类型最初是由子图定义的，所以这看起来有点问题。
让我们仔细看看。我们也可以在 Studio 中查看此模式检查的结果（以及任何过去的检查）。（Rover 在其消息末尾添加了指向此特定检查的链接。）
在 Studio 中前往你的 超级图，然后导航到 Checks 页面。你将在那里看到相同的反映结果。
当我们点击检查时，我们可以看到有关它可能发现的任何问题的更多详细信息。
看起来我们正在处理一个操作顺序问题。模式注册表不知道我们对 listings 子图 所做的更改，所以让我们对我们的 listings 子图 运行相同的检查。
在 listings 上运行检查
在你的终端中，导航到 listings 目录，并运行以下命令。确保你指定了自己的 图形引用。
rover subgraph check <APOLLO_GRAPH_REF> \--schema src/main/resources/schema/schema.graphqls \--name listings
当我们运行此命令时，应该会看到以下输出。
There were no changes detected in the composed API schema, but the core schema was modified.
回想一下，我们只在我们的 listings 模式中更改了一件事：我们将 Listing 类型变成了一个 实体。让我们回到 Studio 并查看 Checks 页面上的新条目。
点击此检查，然后从 TASK 面板中选择 Build。然后，从 WORKFLOW 面板下方，点击 View schema 按钮。
这给了我们两种选择：我们可以查看我们运行检查的 listings 子图模式，或者我们可以查看包含最新更改的整个 超级图模式。现在让我们点击 listings 子图模式 选项。
此选项向我们展示了我们针对其运行检查的完整 子图模式。我们可以看到我们为 Listing 实体 指定的 @key 指令 和主键 字段。
为了解决我们在 reviews 子图 上运行检查时出现的错误，我们只需要在发布时确定我们的操作顺序：首先，我们将发布对我们的 listings 子图 的更改，这些更改将 Listing 注册为一个 实体 类型。然后，我们可以继续发布我们的 reviews 子图 更改，我们的错误将消失！让我们在下一个也是最后一个课程中解决这个问题。
练习
将项目从此框拖到上面的空白处
操作
构建
Linter
子图
已弃用
字段
rover subgraph check 命令需要哪些信息？主要要点
- 模式检查 有助于在模式更新导致生产问题之前识别它们可能导致的潜在故障。
- 构建检查验证 子图 的模式更改是否仍然可以与其他 子图模式 成功组合。
- 操作 检查验证模式的更改是否不会破坏现有客户端发送到 图 的任何操作。
- Linter 检查验证模式是否遵循格式规则和约定。
- 要运行模式检查，我们使用
rover subgraph check命令。 - 我们可以通过终端或 Studio Checks 页面检查模式检查的结果。
接下来
使用 GraphOS 工具（如 Rover 和 Studio），我们已经验证了我们的模式更改是安全的，并且不会破坏任何东西！🎉 接下来，我们将发布我们的子图模式。
分享你关于本课的疑问和评论
此课程当前处于
你需要一个 GitHub 帐户才能在下方发布。还没有？ 改为在我们 Odyssey 论坛上发布。