使用变体管理图环境

在本技术笔记中，了解使用图变体在多个部署环境中进行CI/CD的最佳实践和示例。图 变体在多个部署环境中。

在一个典型的部署架构中，组织设置了多个环境——例如开发、预生产和生产——每个环境都有一个独立的Kubernetes集群和数据库。他们为每个环境创建独立的CI/CD作业，或将它们配置为根据环境特定的变量表现不同。他们在GraphOS中使用针对每个环境专用的图变体，每个变体代表该环境图形的一个特定副本。

典型部署架构的设置从源代码存储库中的代码和模式开始。CI/CD系统既将代码部署到目标部署环境，又将模式发布到GraphOS，然后为部署环境提供模式：

变种源控制分支

您使用的源控制分支模型影响了用于开发特定图 graph 变种的分支。以下是几种常见分支模型的一些示例。

Git flow（特色、开发、主要）

在 Git Flow 中，您通常有一个 develop 分支和一个 main 分支，其中 develop 包含尚未部署到生产环境的正在开发中的代码，而 main 包含生产代码。在这个配置中，您可以创建两个 variant，即 mygraph@develop 和 mygraph@main，它们直接对应于 develop 和 main 分支。

在这个配置中，您可以创建两个 variant，即 mygraph@develop 和 mygraph@main，它们直接对应于 develop 和 main 分支。

feature/* 分支包含某个特定功能的代码。

当为将 feature/* 合并到 develop 而打开一个合并请求时，将执行一系列 schema 检查，以确保这些更改不会在组合或发布更改时损坏 supergraph。

一旦将代码从 feature/* 合并到 develop，CI/CD 工作就会运行以将更改部署到开发环境，并将 subgraph发布到 mygraph@develop 变种。

当 develop 分支中的代码准备就绪后，将合并到 main，触发 CI/CD 工作来将更改部署到生产环境，并将 subgraph发布到 mygraph@main 变种。

在生产环境中，您的 subgraphs 和 GraphOS 路由器会使用配置为从特定 variant 变种拉取的路由器运行。

简化功能分支流程（功能、主要）

类似于Git Flow的分支模型使用 feature 和 main 分支，但不需要 develop。相反，新功能会直接从 main 分支出，当代码完成时，每个 feature 分支将直接合并到 main。在这个模型中，main 代表最新的代码，但不一定是生产环境部署的内容。

在此配置中，您仍然可以拥有两种 变体，即 mygraph@develop 和 mygraph@main，但它们的发布时间与Git Flow略有不同。

feature/* 分支包含某个特定功能的代码。

当创建一个将 feature/* 合并到 main 的拉取请求时，会执行一系列 模式检查，以确保这一系列更改在组合或发布变更时不会破坏 supergraph。

一旦将代码从 feature/* 合并到 main，CI/CD作业会运行将更改部署到开发环境并将子图_subgraph发布到 mygraph@develop 变体

当 main 分支上的代码准备好进入生产环境时，CI/CD作业会运行将更改部署到生产环境并将子图_subgraph发布到 mygraph@main 变体

在部署环境中，您的子图_subgraphs和GraphOS Router以配置为拉取特定 变体的方式运行。

多分支流（feature，develop，preprod，main）

在某些情况下，您可能需要多个分支来容纳多个非生产环境。这可以通过通过将额外的 变体与各种分支相关联来扩展Git Flow配置来实现。

在这个配置中，您可能会为每个部署环境（mygraph@develop，mygraph@preprod，mygraph@main）创建变体，每个变体直接关联到相应的Git分支。

feature/* 分支包含某个特定功能的代码。

当时创建了一个将 feature/* 合并到 develop 的拉取请求时，会执行一系列 模式检查，以确保这些更改在组合或发布时不会破坏 supergraph。

一旦将代码从 feature/* 合并到 develop，CI/CD作业会运行将更改部署到开发环境并将子图_subgraph发布到 mygraph@develop 变体

当 develop 分支上的代码准备进行预生产验证时（例如，用户验收测试），代码会合并到 preprod。随后，会运行CI/CD作业将更改部署到预生产环境并将子图_subgraph发布到 mygraph@preprod 变体

最后，当预生产分支中的代码准备就绪可以投入生产时，它将合并到main分支，并运行CI/CD作业以将更改部署到生产环境并将子图发布到mygraph@main变体

在部署环境中，您的子图和路由器将以从特定变体拉取配置的路由器运行。

运行子图检查

在打开合并请求时使用rover subgraph check进行检查是一个确保更改不会对超级图组成造成问题的良好工具。设置此功能需要CI/CD作业运行于拉取请求事件并执行更新架构上的rover命令。

以下是一个使用GitHub Actions的示例

1
name: Pull Request Check Code
2

3
on: pull_request
4

5
env:
6
  APOLLO_KEY: ${{ secrets.APOLLO_KEY }}
7
  APOLLO_VCS_COMMIT: ${{ github.event.pull_request.head.sha }}
8

9
jobs:
10
  npm-build:
11
    runs-on: ubuntu-latest
12
    steps:
13
      - uses: actions/checkout@v3
14

15
      - uses: actions/setup-node@v3
16
        with:
17
          node-version: 18.x
18
          cache: 'npm'
19

20
      - run: npm ci
21

22
      - run: npm run build
23
  checks:
24
    name: Rover Subgraph Check
25
    runs-on: ubuntu-latest
26

27
    steps:
28
      - name: Checkout
29
        uses: actions/checkout@v3
30

31
      - name: Install Rover
32
        run: |
33
          curl -sSL https://rover.apollo.dev/nix/v0.8.1 | sh
34
          echo "$HOME/.rover/bin" >> $GITHUB_PATH
35

36
      - name: Rover Subgraph Check
37
        run: |
38
          rover subgraph check ${{ secrets.APOLLO_GRAPH_ID }}@develop \ # Specifying the variant here. This might also come from an environment variable, input, etc
39
            --name subgraph-a \
40
            --schema ./src/schema.graphql

发布模式

要使用CI/CD工作从您的系统向GraphOS变体发布模式，您可以使用rover subgraph publish命令。

以下是一个使用GitHub Actions的示例

1
name: Manual Deploy
2

3
on: workflow_dispatch
4

5
env:
6
  APOLLO_KEY: ${{ secrets.APOLLO_KEY }}
7
  APOLLO_VCS_COMMIT: ${{ github.event.pull_request.head.sha }}
8

9
jobs:
10
  deploy:
11
    # Your deployment steps would go here!
12
  publish:
13
    name: Rover Subgraph Publish
14
    runs-on: ubuntu-latest
15

16
    steps:
17
      - name: Checkout
18
        uses: actions/checkout@v3
19

20
      - name: Install Rover
21
        run: |
22
          curl -sSL https://rover.apollo.dev/nix/v0.8.1 | sh
23
          echo "$HOME/.rover/bin" >> $GITHUB_PATH
24

25
      - name: Rover Subgraph Publish
26
        run: |
27
          rover subgraph publish ${{ secrets.APOLLO_GRAPH_ID }}@develop \ # Specifying the variant here. This might also come from an environment variable, input, etc
28
            --name subgraph-a \
29
            --routing-url http://graphql.mygraph.svc.cluster.local:4000 \
30
            --schema ./src/schema.graphql