概览
我们现在已经架构检查是我们工具带中的工具，因此让我们看看它们如何应用到 listings 子图谱中的更改。
在本课中，我们将
- 查看本地开发环境中的代码更改
- 查看值类型和
@shareable架构中的指令 - 了解如何使用 Rover在本地运行架构检查
查看样机
让我们再次了解星系坐标项目需要什么内容。
我们需要列表详细信息页面来显示列表及其主机的星系坐标。星系坐标将以纬度和经度值的组合形式显示。
提示：你不会和课程一起编码，但是当我们实现这些代码更改时，请注意我们介绍的步骤和概念！
Airlock 团队拥有两名成员负责此功能，每人来自一个 子图 团队：
- 👩🏽🏫 房源团队的 Lisa
- 👩🏽🚀 账户团队的 Achilles
我们将帮助他们结合我们在之前课程中（模式检查 和 图形 变体）学到的知识融入到他们的开发流程中！
local 开发环境中的变更
👩🏽🏫 房源团队的 Lisa 已开始针对此功能展开工作，具体做法是对模式、数据解析器和数据源进行补充。我们不妨了解一下他们为启动此功能所做的工作。
listings 子图 现已包含一项新类型： GalacticCoordinates。此 对象类型 具有纬度和经度（两者均为非可空 Float）。
"Coordinates in the galaxy"type GalacticCoordinates {latitude: Float!longitude: Float!}
GalacticCoordinates 类型是 值类型 的示例。值类型是跨多个 子图 重复使用和共享的类型。此类类型可以是 对象类型、枚举、联合或接口。我们在 Voyage II 中看到了接口作为值类型的示例。
现在，GalacticCoordinates 对象类型仅在 listings 子图中使用，但记住，我们还需要显示属于 宿主位置的 accounts子图。 @shareable 指令将使这两个 子图解析此类型。
注意：如果您已完成航程 II，我们在讨论字段共享时简要地介绍了 @shareable 指令。请注意，对象类型（例如 GalacticCoordinates）的值类型需要使用 @shareable 指令，但接口（如我们在航程 II 中介绍的内容）则不需要。
Lisa 将需要向 @shareable 指令添加到 GalacticCoordinates类型。
"Coordinates in the galaxy"type GalacticCoordinates @shareable {latitude: Float!longitude: Float!}
最后，Lisa 还向 Listing 实体添加了一个 字段： coordinates。此 字段返回 GalacticCoordinates类型。
type Listing @key(fields: "id") {# … other listing fields"Where this listing is located in the galaxy"coordinates: GalacticCoordinates}
Lisa 已经为 解析器 和 数据源 实现了代码，以检索此新 字段 的正确数据。
太好了，这些更改应该能够帮助我们入门！让我们重新审视下一步的 CI 流程：将代码推送到 GitHub 并开启 PR。
不过，别忘了我们工具带中有个新条目： 架构检查。我们可以在 推动代码之前在本地运行架构检查。这将使我们能够捕获并解决与 合成 或现有 操作 相关的任何错误。
运行本地架构检查
要运行本地架构检查，我们将使用 rover subgraph check 命令，采用以下参数：
rover subgraph check <GRAPH_NAME>@<GRAPH_VARIANT> \--schema <SCHEMA_FILE_PATH> \--name <SUBGRAPH_NAME>
我们需要检查我们的本地 子图对于 暂存 变体, 给它我们的 listings.graphql 架构文件和 子图的名称 listings. 在用我们 子图的值替换参数后，命令看起来像这样：
rover subgraph check airlock-managed-fed@staging \--schema "listings.graphql" \--name listings
因为 Airlock 是一种 超级图, 构建检查将首先运行，然后 操作 检查.
流程完成后，我们可以看到架构变更报告。终端输出显示以下内容
Checking the proposed schema for subgraph listings against airlock-managed-fed@stagingCheck Result:Compared 4 schema changes against 16 operations┌────────┬─────────────┬─────────────────────────────────────────────────────┐│ Change │ Code │ Description │├────────┼─────────────┼─────────────────────────────────────────────────────┤│ PASS │ TYPE_ADDED │ type `GalacticCoordinates`: created │├────────┼─────────────┼─────────────────────────────────────────────────────┤│ PASS │ FIELD_ADDED │ type `GalacticCoordinates`: field `latitude` added │├────────┼─────────────┼─────────────────────────────────────────────────────┤│ PASS │ FIELD_ADDED │ type `GalacticCoordinates`: field `longitude` added │├────────┼─────────────┼─────────────────────────────────────────────────────┤│ PASS │ FIELD_ADDED │ type `Listing`: field `coordinates` added │└────────┴─────────────┴─────────────────────────────────────────────────────┘
第一列指示每个变更是否通过或未通过检查。第二列指示我们做出的变更类型，如 TYPE_ADDED 或 FIELD_ADDED. 最后一列提供变更的更详细描述，如创建了哪个准确类型以及在该类型下添加了哪个 字段.
太赞了，我们没有错误！我们可以看出构建检查已通过，因为输出表中的每一行都有 PASS 状态。架构变更也与现有的客户端 操作进行了比较，并且未检测到任何重大变更。
让我们回想一下我们的开发流程。我们已经完成了第一步，甚至通过添加本地架构检查改进了我们的流程。
实践
rover subgraph check 命令需要以下哪种信息？rover subgraph check 命令针对非联合图运行哪些类型的 schema 检查？重点提示
- 我们使用
rover subgraph check命令来本地执行 schema 检查。 -
@shareable指令 允许多个 子图 解析特定的对象 字段（或对象字段集）。
接下来
让我们继续改进我们的工作流程。在下一课中，我们将向我们的 CI 管道添加 schema 检查，以便只要创建 PR 就能自动运行它们。
分享你对本课的问题和评论
你的反馈有助于我们提升！如果你遇到困难或困惑，请告知我们。所有评论都是公开的，并且必须遵守 Apollo 行为准则。请注意，已解决或解决的评论可能会被移除。
需要有一个 GitHub 账户才能在下方发帖。没有账户？ 转而在我们的 Odyssey 论坛发帖。