概述

欢迎来到航程系列的第三个也是最后一个课程！

到目前为止，我们已经使用了Apollo Federation对 图形进行模块化，以用于一个新的绿色字段项目和一个现有的单体应用程序。在这两种情况下，我们都在个人计算机上为应用程序图形的模式进行了本地处理。但是，当需要向生产环境部署应用程序时会发生什么情况？

在本课程中，我们将深入探讨 托管联合会的优势，以及如何使用 Apollo GraphOS工具来监视和更改 超图谱在生产环境中。

在本课中，我们将

• 探索在我们的 Airlock 演示应用程序中添加新功能
• 查看 Airlock 的当前架构
• 了解开发工作流中使用的环境、工具和流程

先决条件

需要熟悉联邦制和受管理的联邦制的基本概念，例如：

• 在联合架构中路由器的用途以及它如何与子图协同工作
• 如何使用Rover向架构注册表发布子图
• 如何运行GraphOS 路由器

我们在Voyage I中介绍了这些概念。

还需要熟悉

• 在终端中运行命令，例如在目录间导航
• 基本的 Git 概念，例如分支、拉取请求和合并

我们将学习如何将某些概念集成到开发工作流程中，但这并不需要预先了解持续集成和持续交付 (CI/CD) 的原理。要快速了解，可以阅读 GitHub 的 CI/CD 概述。

如何学习

本课程与你迄今为止完成的先前Odyssey课程有点不同。为了展示概念如何在现实世界中发挥作用，本课程将使用来自Voyage II的 Airlock 应用程序来演示如何在生产中使用受管理的联邦制。

但是，Airlock 由多项服务组成，而单独部署这些服务需要一点设置工作。本教程的重点是 托管联合产品，而不是部署新功能！

因此，在本课程中，您不会通过在自己启动的项目中执行确切的步骤来学习。相反，您可以阅读本文档，了解基本概念和如何将其应用于您自己的 CI/CD 管道。每节课结尾都会有一个 演练部分，其中包含评估问题，以便您可以检查您对关键理念的理解。

进化图表

让我们重新审视 Airlock，我们的星际旅行应用程序，太空探险者可以在其中找到新的星系际旅行地！

Airlock 团队一直在寻求改善用户体验。现在，他们希望专注于客户体验。客户预订了旅行后，他们很难找到确切的入住地点。有时，房东甚至会给他们错误的空间地址！此外，客户还经历了一些沮丧的体验，因为到达后房东根本不在该位置。他们一直在期待有人热情欢迎和提供快速服务。

为了解决这些客户投诉，Airlock 团队正在处理一个新的项目： 银河坐标系项目.该项目改进了客户轻松找到以下两项内容的方法：他们预订的列表和拥有该列表的房东。有了精确的银河坐标系后，客户将确信自己住在正确的地方，而且他们将知道房东在哪里！此关键信息将设定我们客户正在预订的房源的更清晰期望值。

银河坐标系项目的已创建设计，因此，让我们看看！

从模型设计中，我们可以看到对于每个清单和房东，我们都需要新的数据信息：银河坐标系。这些坐标由纬度和经度组成，两者都是精确定位星系中清单或房东位置的数字。

我们可以开始评估如何将该新数据部件整合到我们现有架构中。此类数据应属于哪种？哪些类型需要新的 字段，又属于哪个 子图？花点时间回顾一下屏幕设计图，并构思 您将如何调整 图表以纳入此项新功能。

🚀 Airlock 已部署至生产环境

在我们着手解决如何实施此项新功能之前，让我们先回过头来了解一下 Airlock 的当前架构、它有何变化，以及它是如何部署至生产环境的。

最初的 Airlock 采用整体式 GraphQL 架构，我们对其进行了迭代分割，将其拆分至 子图 并将其转换为完全联合的架构。出于航海 II 课程的目的，所有这些工作均在本地完成，每个 子图服务器 和 路由器 都托管在本地端口上。

自那以后，团队已部署每项服务、子图和 路由器，以使其在本地计算机外部也能获得。Airlock 已正式投入生产！

您应该已熟知来自 子图 和服务的 航海 II。

Airlock 的已部署版本使用 托管联合。在 航程 I中回顾一下，使用 托管联合意味着每个 子图都会发布到 Apollo 架构注册表，然后架构注册表将处理我们的 组合。 路由器轮询 Apollo Uplink 以检索最新版本的 超级图架构供其使用。（需要快速复习？请查看下方托管联合流程的图表。）

通过此设置，我们在 Studio 中提供了 Airlock 图形。在以下屏幕截图中，我们可以看到 API 架构和所有参与的 子图：

我们还将开始探索更多 Studio 的功能，以及它们如何支持我们发展 图形。

开发工作流

Airlock 团队应用持续集成和持续交付 (CI/CD) 原则，这意味着新的代码更改会定期合并到主代码库中，并交付到不同的环境中。

让我们来看看 Airlock 团队迄今为止用来发展 图形的工具、环境和流程。

工具

我们使用了一些不同的工具来启动并运行 Airlock

• GraphOS Studio ：这是我们查找 模式注册表 的地方，同时还可以与我们的 图表 交互并追踪其运行状况的许多其他有用方法。我们将在本课程中更多地了解 Studio。

• Rover CLI：我们在本地环境中使用 Rover 来发布 子图 并运行 模式检查（我们稍后会了解）。我们还将学习如何将 Rover 集成到我们的 CI/CD 流程中。

• GitHub ：我们的代码在此处，以便团队内更轻松地进行协作和版本控制。

• GitHub Actions ：我们自动化 CI/CD 工作流的方式。这些工作流可以由某些事件触发，例如创建或关闭拉取请求、分支上的新提交，甚至可以通过按一下按钮来手动触发。

• Heroku ：一个云服务平台，使我们能够部署应用，而无需担心具体的基础设施。

环境

复杂应用程序几乎总是在多个环境中运行，每个环境都有不同的目的。你可以将环境想象成一个独立的空间，有自己的代码实例和环境变量。我们在三个不同的环境中运行 Airlock： 本地开发、 临时部署和 正式部署。

• 本地：开发人员的本地工作区，在其自己的计算机上运行。任何代码或模式更改都从这里开始。
• 临时部署：临时部署环境通常用于在正式部署之前测试和验证更改。
• 正式部署：这是用户实际交互的应用程序的“实时”版本。

我们将重点关注这些环境如何在服务器端使用我们之前概述的工具工作。

路由器、子图和服务在 GitHub 上都有自己的储存库。下图显示了 Airlock 储存库的完整列表。

这些代码库中的每一个都通过其自己的应用程序托管在 Heroku 上。路由器和子图服务器各自有两个 Heroku 应用程序：一个用于暂存实例，一个用于生产实例。这些实例是完全分开的，它们有不同的GraphQL端点 URL。

这些服务也托管在 Heroku 上，但它们每个只都有一个生产实例。

下图展示了本课程中我们关注的所有 Airlock 应用程序。

那么 GitHub 储存库和 Heroku 应用是如何连接的呢？

让我们仔细看看accounts 子图作为示例。当我们将更改合并到 GitHub 上main分支中的subgraph-accounts存储库时，我们的 CI/CD 管道首先将新版本的代码部署到暂存环境，这样我们就可以检查所有内容是否都按预期工作。

如果一切看起来都不错，我们随后会将相同版本的代码部署到生产环境，这样真正的 Airlock 用户才可以访问。我们将在下一部分中更详细地介绍此过程。

如果我们的更改包括对子图架构进行更新，我们还将使用Rover CLI将新子图发布到架构注册表中。（目前，Airlock 图仅跟踪图的生产版本，但我们稍后将探讨如何在后面镜像我们的暂存环境中添加图变体。）

下图显示了将更改运送到子图的高级开发过程，从本地开发到生产部署。

流程

现在我们熟悉所使用的环境和工具，让我们更深入地了解开发流程以及我们的 CI/CD 管道如何工作。此流程在我们对子图进行更改时开始，例如添加字段或更改字段描述。

CI 工作流

首先，我们在本地环境中的单独分支中进行架构和代码更改。接下来，我们将更改推送到 GitHub 仓库并创建一个请求合并（PR）。团队成员会在合并 PR 到 main分支之前审查 PR 并做出必要的更改。此 PR 合并会自动触发 CD 工作流。

CD 工作流

对 main分支的更新会通过 GitHub 操作自动部署到 Heroku 上的暂存环境。在暂存环境中进行初始测试。如果一切看起来都不错，则将相同的更改手动部署到生产环境。我们将在浏览器中的 GitHub Actions UI 中执行此操作。

成功部署到生产环境后，将触发另一个 GitHub 操作。它会将架构更改发布到 Apollo 架构注册表，并且GraphOS会启动合成。然后路由器可以从 Uplink 获取最新的超图架构

实践

重要要点

• Airlock 使用在其他项目中常见的三个开发环境：本地环境、暂存环境和生产环境。

• 我们使用 CI/CD 流程来更改我们的 图并自动将这些更改部署到不同的环境中。

下一步

在本课程中，我们将学习如何通过 图 变量和 架构检查来改善 CI/CD 工作流。在努力将 Project Galactic Coordinates 推向全球之时，这两个新增功能将帮助我们识别和防止对图表进行重大更改。我们还将利用 托管联合来涵盖可观察性，以检查我们图表的运行状况。

我们将在下一课中首先了解 图 变量。