概览
现在是 GraphOS 不可或缺的一个组成部分的时候了GraphOS：架构注册表！
在本课程中，我们将
- 了解 GraphOS 架构注册表及其用途
- 了解 GraphOS 启动 流程
- 使用 Rover CLI 将架构发布到架构注册表
- 在 Studio 中检查 启动 的结果
什么是架构注册表？
从本质上讲，架构注册表是我们的架构的一个版本控制系统。它存储我们的架构更改历史记录，跟踪已添加、修改和删除的类型和 字段。注册表支持 Apollo GraphOS 的几乎所有功能。
类似于我们将变更提交并推送到 Git 仓库中代码库，我们应该将 子图模式的每个新版本推送到注册中心中。注册中心负责跟踪所有子图并将其组合为一个 超图模式。多亏了注册中心，我们才能运行 模式检查，就像我们在上一节课中所做的那样。GraphOS会根据存储在注册中心中的模式检查我们的模式变更。
在本课程中，我们从一个 子图在我们的 超图中开始。随着我们开始添加更多子图，我们将继续利用模式注册中心的力量！
当我们将 子图模式的新版本发布到注册中心时，我们触发在 GraphOS中的 启动。
启动过程
一个 启动表示向 图形更新模式的完整过程。
当模式注册中心获取 子图模式的新版本或更新版本时，它开始 构建 超图模式。模式注册中心尝试将所有模式从其注册的 子图合并到一个超图模式中。这个过程也称为 组合。
如果合并失败，我们将在 Studio 中看到一个错误，流程会到此停止。不要紧张：我们可以使用错误信息在子图中修复此问题，然后再次尝试用Rover发布子图。
如果合并成功且没有验证错误，架构注册表会生成超图架构。
架构注册表会自动将超图架构发送到GraphOS中的内部服务中，名为 Apollo Uplink。Uplink是一个服务器，用于存储每个图的最新超图架构。路由器从 Uplink 提取最新架构，并使用此新架构来响应客户端请求。
由此，发布完成！
协调架构和代码变更
到目前为止，我们只讨论了架构变更以及如何将其发布到GraphOS中。但我们不能忘记代码库变更！这些变更包括我们对解析器函数的更改，以便使我们的架构和架构文件本身正常工作。我们需要将本地变更部署到生产环境中。
要协调架构和代码变更，计划如下
将代码库变更（我们对
schema.graphql和resolvers.js所做的更改）合并到 GitHub 存储库的main分支中。将 子图服务器的运行时代码部署到 Railway（此操作会自动完成，Railway 正在监听我们 GitHub
main分支的变更）。向 GraphOS发布 子图架构（这会触发 启动流程）。
理想情况下，这可以通过我们的 CI/CD 管道完成所有后续工作。首先，我们将手动演示此流程，以熟悉我们需要的命令及其结果位置。在下一节课程中，我们将使用 GitHub Actions 设置一个 CI/CD 管道来自动完成此操作。
注意：根据你选择的部署平台，你的计划可能有所不同！例如，Railway 会自动部署 main分支中的最新变更，但你可能希望对该流程有更多控制，或从其他分支部署。或许你有一个预生产环境用于在发布到生产环境之前测试变更。我们在 航程 III 课程中介绍了在发布流程中添加 staging环境时发布流程可能会是什么样子。你还可以在 这篇 Apollo 技师说明中详细了解部署变更的常规流程。
合并代码库变更
好的，让我们开始吧！首先，让我们合并我们的代码库变更。
让我们提交之前所做的变更并直接将它们推送到 main分支。(我们现在处于教程环境中，所以这样做是可以的！在下一节课中，你将看到更符合实际情况的流程，使用 CI/CD 工作流)。
打开一个新的终端。
添加我们更改的文件。
git add schema.graphql src/resolvers提交这些变更，并附加一条消息，清楚地解释我们已完成的操作。
git commit -m "Deprecate Ingredient.text field. Use detailedDescription instead."将变更推送到 GitHub 仓库。
git push -u origin main
第一步完成！
✅ 将我们的代码库更改合并到我们 GitHub 存储库的
main分支中。⏭️ 将子图服务器的运行时代码部署到 Railway。
将 子图模式发布到 GraphOS。
第 2 步不需要我们做太多工作！一旦我们更改登陆 main分支，Railway 将自动开始其部署过程。
前往你的 Railway 应用程序并查看加载栏，直到它显示已成功无问题地部署！如果你导航到你的服务器 URL，不会有任何可见更改，但我们知道，在这背后，这个 子图准备好了一个新的 字段和一个弃用的字段！
✅ 将我们的代码库更改合并到我们 GitHub 存储库的
main分支中。✅ 将子图服务器的运行时代码部署到 Railway。
⏭️ 将子图模式发布到 GraphOS。
让我们解决最后一步！
rover subgraph publish
我们需要将我们的新 子图模式发布到 GraphOS。
要执行此操作，我们会使用 Rover CLI的 rover subgraph publish命令，使用以下参数：
rover subgraph publish <GRAPH_REF> \--schema <SCHEMA_FILE_PATH> \--name <SUBGRAPH_NAME>
它看起来非常类似于 rover subgraph check命令！
注意：请记住，你可以在 Studio 的图形的 README 页面的顶部找到你的 图形引用。
发布我们的子图更改
让我们开始吧！在终端窗口中，粘贴 rover subgraph publish命令。确保将参数替换为 你自己的值。
rover subgraph publish learning-cats-supergraph@current \--schema schema.graphql \--name space-courses
如果一切顺利，我们应该会看到终端输出和一条消息，确认 子图已发布，超图已更新！
在 Studio 中检查启动
将架构发布到注册表后会发生什么？启动开始了！让我们看看 Studio 中的这个流程。
导航至 启动页面。单击列表中的最新 启动。
我们可以看到此特定 启动的 启动序列部分遵循我们之前讨论的步骤：
- 构建完成是指构建 超图架构的过程（也称为 合成）。
- 已发布架构指的是 超图架构已提供给 Apollo Uplink。
- 启动完成不言自明！我们的启动已成功完成！🎉
在右侧，我们还可以查看 超图架构输出和架构更改的摘要。
如果一切看起来都很顺利，我们应该可以 查询新 detailedDescription 字段以获取成分。
让我们转到 Explorer 并运行 查询以检索随机食谱的成分及其详细说明。
query GetRandomRecipeIngredients {randomRecipe {ingredients {detailedDescription}}}
您应该会看到数据返回！让我们再试一次，这次在 查询中添加 text。
query GetRandomRecipeIngredients {randomRecipe {ingredients {detailedDescriptiontext}}}
查询仍然正常运行并成功返回，但我们在 Studio 中收到警告（这条黄色的波浪线警告！）称 text已弃用，不再使用。
我们发布成功了！🎉
练习
重点要点
- schema registry 是我们 schema 的版本控制系统。它存储我们 schema 的更改历史记录，跟踪已添加、已修改和已删除的类型和 字段。注册表负责跟踪所有 子图并将其合成一个 超级图 schema。
- 一个 发布表示对 图执行 schema 更新的完整过程。在将 schema 发布到 GraphOS时，会触发 发布。
- 要发布 子图 schema，请使用
rover subgraph publish命令。 - 我们可以通过 Studio 的 发布页面来检查 发布的结果。
接下来
干得漂亮！我们已经借助GraphOS安全而自信地对超图谱超图谱做出了更改。我们通过手动完成所有这些步骤实现了更改，运行模式检查并从终端发布命令，但这些工作实际上应该存在于自动化 CI/CD 管道中。下节课我们将设置好一个管道！
分享你对本课程的问题和意见
此课程当前处于
你需要一个 GitHub 帐户才能在下面发帖。还没有吗？ 转到我们的 Odyssey 论坛发帖。