概述
现在我们已经更新了我们的代码库,是时候部署代码、发布我们的模式和我们的图形 变体
- 学习如何自动将更改部署到暂存环境和生产环境
- 学习如何将暂存环境中的部署步骤应用到生产环境中
- 了解如何将架构更改发布到
暂存
变体作为 CD 管道的一部分
在 CD 工作流中发布到架构注册表
这张图表展示了一张流程图,概述了以下流程
- 暂存部署。将代码部署到暂存环境进行测试。此作业自动完成,在成功合并 PR 后触发。
- 生产部署。将代码部署到生产环境。此作业在暂存环境中完成测试后手动触发。
- 将架构发布到注册表(产品环境 图谱)。在产品环境成功部署后,将自动触发此操作。
最初,Airlock 图谱仅跟踪图谱的生产版本(current
变体)。在课程前期,我们向 图谱中添加了一个 staging
变体,以对应 子图谱的暂存环境。务必更新我们的 CD 工作流!
部署到暂存环境后,我们将发布 子图谱架构的变更至 staging
变体,这会触发 启动过程。此流程将全部由两个单独的 GitHub Actions 自动完成,我们将在下一部分中详细了解这两个 Actions。
下图显示了我们更新后的 CD 工作流,用于暂存部署。我们将为生成环境部署提供一个单独(且类似!)的图表。
这张图表展示了一张流程图,概述了以下流程
- 暂存部署。将代码部署到暂存环境进行测试。此作业自动完成,在成功合并 PR 后触发。
- 将架构发布到暂存 图谱 变体。在暂存部署成功后,将自动触发此操作。
- 启动过程开始。 GraphOS启动启动过程(组合、操作检查等)。
暂存部署
空闸 CD 管道包含一个称为 暂存部署的 GitHub 操作,负责将代码部署到 Heroku 上的暂存环境。当将拉取请求合并到 main
分支时,此作业会自动触发。
subgraph-accounts/.github/workflows/deploy-staging.yml
if: ${{ github.event.pull_request.merged == true }}
heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
heroku_app_name: ${{ secrets.HEROKU_APP_NAME_STAGING }}
heroku_email: ${{ secrets.HEROKU_EMAIL }}
此操作会保持 Heroku 暂存应用与 GitHub 仓库的 main
分支同步。
将架构发布到暂存阶段
在 暂存部署 作业运行之后,另一个作业会自动开始: 暂存发布架构 作业。此作业会将 子图架构 发布到架构注册表中的 staging
变体。
subgraph-accounts/.github/workflows/publish-schema-staging.yml
name: Staging Publish Schema
workflows: ['Staging Deploy']
name: Publish schema to staging variant
if: ${{ github.event.workflow_run.conclusion == 'success' }}
APOLLO_KEY: ${{ secrets.APOLLO_KEY }}
APOLLO_VCS_COMMIT: ${{ github.event.pull_request.head.sha }}
GRAPH_ID: airlock-managed-fed
curl -sSL https://rover.apollo.dev/nix/v0.1.0 | sh
echo "$HOME/.rover/bin" >> $GITHUB_PATH
- name: Publish subgraph to staging registry
rover subgraph publish ${GRAPH_ID}@staging --schema ./${SUBGRAPH}.graphql --name $SUBGRAPH
该作业在幕后使用 rover subgraph publish
命令将架构更改发布到 子图 在 GraphOS 中。
查看 CD 工作流的实际情况
让我们看看作业的实际情况!在新房源团队检查完拉取请求中的更改后,我们可以单击 合并 以将更新合并到新房源 子图 的 main
分支中。
这将触发 Staging 部署 作业,以将更改部署到 listings
子图 的 staging 环境。
以下是 GitHub Actions 页面的屏幕截图,显示了到目前为止已运行的工作流。当前,Staging 部署 作业正在为刚刚合并的 PR 运行。
单击 Staging 部署 作业时,我们可以关注作业进度,直至完成。
在作业成功完成后,它会触发下一个作业,发布 staging 模式,该作业会将新的 listings
子图模式 发布到 staging
变体 上的 GraphOS。
单击了解作业的详细信息后,我们可以看到模式已成功发布到 staging
变体 中。
模式发布到注册表后会怎么样?启动 开始了!我们可以在 Studio 的 启动 页面中看到启动过程中的步骤,确保我们选择了 staging
变体 的 图表。
https://studio.apollographql.com
现在,丽莎对 listings
子图 所做的更改已在 Airlock 的暂存环境中可用。团队成员和其他利益相关者可以使用 Apollo Explorer 测试新的 超图,并确保一切都按预期工作。
部署到生产环境
在完成暂存环境中的商品展示银河坐标的初步测试后,我们可以尝试部署到生产环境。
下图展示了我们应用程序生产工作流程中的步骤,这在很大程度上类似于我们的暂存环境计划!
这张图表展示了一张流程图,概述了以下流程
- 生产部署。手动将代码部署到实时生产环境。
- 将架构发布到生产 图形 变量。每个成功的生产部署后都会自动触发此操作。
- 启动过程开始。 GraphOS启动启动过程(组合、操作检查等)。
当我们准备好更新我们的生产环境时,我们首先要将我们的 main
代码分支部署到对应 Heroku 应用程序的生产版本。为此,我们可以在 GitHub 上手动运行 Production Deploy 作业。
这将把我们从 GitHub 上的 main
分支推送到在 Heroku 上托管的生产环境中的最新代码更改。当此操作成功后,将触发一个名为 Production Publish Schema 的另一项作业,该作业会将我们图形的 子图架构 发布到 current
变量 中。这会启动一个新的 启动,然后我们回到我们在暂存环境中已涵盖的相同流程中!
有兴趣了解使用 GitHub 的具体操作吗?请参阅以下详细步骤和屏幕截图!
导航到 Actions 页面,从列表中选择 Production Deploy。
单击 Run workflow 下拉菜单,选择 main
分支,然后单击 Run workflow 以启动工作流。
以下是该作业的工作流文件
.github/workflows/deploy-prod.yml
name: Deploy to production
heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
heroku_app_name: ${{ secrets.HEROKU_APP_NAME }}
heroku_email: ${{ secrets.HEROKU_EMAIL }}
刷新页面并选择已启动的作业。当此作业成功完成后,另一个作业将被触发。
返回操作页面并从列表中选择发布生产架构工作流。我们将看到有项新作业正在运行。
以下是该作业的工作流文件
.github/workflows/publish-schema-prod.yml
name: Publish Schema Production
workflows: ['Production Deploy']
name: Publish schema to current variant
if: ${{ github.event.workflow_run.conclusion == 'success' }}
APOLLO_KEY: ${{ secrets.APOLLO_KEY }}
APOLLO_VCS_COMMIT: ${{ github.event.pull_request.head.sha }}
GRAPH_ID: airlock-managed-fed
curl -sSL https://rover.apollo.dev/nix/v0.1.0 | sh
echo "$HOME/.rover/bin" >> $GITHUB_PATH
- name: Publish subgraph to production registry
rover subgraph publish $GRAPH_ID --schema ./${SUBGRAPH}.graphql --name $SUBGRAPH
- 等待此作业成功完成。接下来,它将在GraphOS中触发发布,你可在发布页面的
当前
变体的图形中找到该发布
https://studio.apollographql.com
当我们希望更新路由器的配置方式时会发生什么?让我们花点时间看看更改和部署更改的过程!
路由器的所有代码都存放在一个 GitHub 存储库中。它包括路由器二进制文件、config.yaml
配置文件和一个Procfile,它特定于托管路由器的 Heroku。
像任何其他 GitHub 存储库一样,我们可以在本地克隆并运行路由器仓库。当我们进行更改时,我们将打开一个新的 PR,然后(一旦得到批准!)将新代码合并到仓库的main
分支。在此基础上,可以准备进行一些事情。
这张图表展示了一张流程图,概述了以下流程
- 架构和代码更改是在本地环境中的一个单独分支中进行的。
- 创建一个拉取请求 (PR) 以合并到
main
分支中。PR 会被审查并合并到主分支中。 - 暂存部署。将代码部署到暂存环境进行测试。此作业自动完成,在成功合并 PR 后触发。
- 生成部署。将代码部署到生成环境中。此作业将手动触发。
将router仓库设置为在 Heroku 上部署到两个应用:一个是 staging 环境,另一个是生产环境。正如我们在子图仓库中看到的那样,当我们将代码合并到main
分支时,会自动部署到 staging 环境。
当我们在 Heroku 上查询我们的 staging 应用时,我们在针对图的staging
变体进行操作。这是因为我们已将 Heroku 应用配置为使用APOLLO_GRAPH_REF
和APOLLO_KEY
环境变量连接到staging
变体。
https://studio.apollographql.com
尽管会自动部署到 staging 应用,但我们不希望以相同的方式将我们的更改推送到生产环境。一旦我们对staging
变体的更新进行了测试,并且确信我们的router按预期运行,我们便可以手动触发将main
分支部署到我们的router在 Heroku 上的生产应用。生产应用针对current
变体运行操作。
https://studio.apollographql.com
我们需要路由器两个实例分别测试我们的路由以staging
和current
graph variants。赫罗库允许我们在路由的router's Procfile
中设置一个命令,该命令指定在不同环境中运行路由时要使用的环境变量。
该图表展示了我们用于运行路由的命令。在此,我们通过以下占位符引用两个环境变量:$APOLLO_KEY
和$APOLLO_GRAPH_REF
。
这些环境变量的值根据其所用的环境而设置。Staging 将使用与生产环境不同的APOLLO_KEY
,而APOLLO_GRAPH_REF
在 staging 和生产环境中由“@”符号后的variant集设置不同。在 staging 中,我们引用staging
variant,而在生产环境中,我们引用current
。
通过保持我们每个环境的部署方法分开,我们可以确保我们对路由或其config.yaml
文件所做的任何更改继续正确工作。
实践
要点
- 我们可以使用 子图来将发布
rover 子图发布
命令自动发布到管道内的注册表中。 - 发布 子图架构到注册表中的任何 变量都会触发 启动。我们可以通过 Studio 的启动页面查看启动顺序。
接下来
完成了!我们将发布到架构注册表的操作集成了 CD 管道,系统会自动为我们运行!我们此处已经顺利通过所有检查,但在接下来的两堂课中,我们会看到事情进展不 顺利时的情况。