Now that we've updated our codebase, it's time to deploy the code, publish our schemas, and make use of our graph variants.
In this lesson, we will:
- Learn how to automatically deploy changes to the staging and production environments
- Learn how to apply the deployment steps from the staging environment to the production environment
- Learn how to publish schema changes to the
stagingvariant as part of the CD pipeline
Publishing to the schema registry in the CD workflow
Let's review the original CD workflow.
Originally, the Airlock graph only tracked the production version of the graph (the
current variant). Earlier in the course, we added a
staging variant to the graph to correspond to the staging environment of our subgraphs. Let's make sure to update our CD workflow!
After deploying to the staging environment, we'll publish our subgraph schema changes to the
staging variant of our graph, which will trigger a launch. This process will all be taken care of automatically by two separate GitHub Actions, which we'll take a look at in the next section.
The diagram below shows our updated CD workflow, for the staging deploy. We'll have a separate (and similar!) diagram for the production deploy.
The Airlock CD pipeline includes a GitHub Action called Staging Deploy, which is responsible for deploying the code to the staging environment on Heroku. This job is automatically triggered when a pull request is merged to our
This takes care of keeping the Heroku staging apps up to date with the
main branch of our GitHub repo.
Publish schema to staging
After the Staging Deploy job runs, another begins automatically: the Staging Publish Schema job. This job publishes the subgraph schema to the
staging variant in the schema registry.
This job uses the
rover subgraph publish command behind the scenes to publish the schema changes to the relevant subgraph in Studio.
Seeing the CD workflow in action
Let's see the jobs in action! After the Listings team has reviewed the changes in the pull request, we can click Merge to merge the updates into the
main branch of the listings subgraph's repository.
This triggers the Staging Deploy job to deploy the changes to the Heroku app for the
listings subgraph's staging environment.
Here's a screenshot of the GitHub Actions page showing the workflows that have run so far. Currently, the Staging Deploy job for the PR that was just merged is running.
When clicking the Staging Deploy job, we can follow the job's progress until it completes.
After the job successfully completes, it triggers the next job, Staging Publish Schema, which publishes the new
listings subgraph schema to the
staging variant on Apollo Studio.
Clicking into the details of the job, we can see the schema was successfully published to the
What happens after a schema is published to the registry? A launch starts! We can see the steps in the launch process in the Launches page of Apollo Studio, making sure we have the
staging variant of our graph selected.
We can see that Launch Sequence section for this specific launch follows the steps we had covered in lesson 4: Schema checks in a supergraph. And this launch completed successfully! 🎉
Now, Lisa's changes to the
listings subgraph are available in Airlock's staging environment. Teammates and other stakeholders can use the Apollo Explorer to test out the new supergraph and make sure everything works as expected.
Deploying to production
After initial testing on displaying the galactic coordinates for a listing on the staging environment is completed, we can try out deploying to production.
The diagram below illustrates the steps in our app's production workflow—and it looks a lot like our plan for the staging environment!
When we're ready to update our production environment, we first want to deploy our
main code branch to the production version of the corresponding Heroku app. To do this, we can run the Production Deploy job manually on GitHub.
This pushes the latest code changes from the
main branch on GitHub to the production environment hosted on Heroku. When this succeeds, it triggers another job called Production Publish Schema, which publishes the updated subgraph schema to our graph's
current variant. This initiates a new launch, and we're back in the same process we've already covered in the staging environment!
- We can automate publishing a subgraph to the registry inside our CD pipeline using the
rover subgraph publishcommand.
- Publishing a subgraph schema to any variant in the registry triggers a launch. We can view the launch sequence in the Launches page of Apollo Studio.
And there we go! We've integrated publishing to the schema registry into our CD pipeline, running automatically for us! All our checks passed successfully here, but in the next two lessons we'll see what happens when things don't go smoothly.