7. Publishing & deployment
5m

Overview

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 staging variant as part of the CD pipeline

Publishing to the schema registry in the CD workflow

Let's review the original CD workflow.

Diagram of the original CD workflow. See detailed image description below.

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.

Diagram of the updated CD workflow - focusing on the staging environment. See detailed image description below.

Staging 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 main branch.

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.

https://github.com
Screenshot of GitHub Actions with Staging Deploy job in progress

When clicking the Staging Deploy job, we can follow the job's progress until it completes.

https://github.com
Screenshot of GitHub Actions with Staging Deploy job completed

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.

https://github.com
Screenshot of GitHub Actions with Publish Schema to Staging job in progress

Clicking into the details of the job, we can see the schema was successfully published to the staging variant.

https://github.com
Screenshot of Publish Schema to Staging job in GitHub completed

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.

https://studio.apollographql.com
Screenshot of Launches page in Apollo Studio

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!

Diagram of the updated CD workflow - focusing on the production environment. See detailed image description below.

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!

Practice

Which of the following events triggers a launch in Apollo Studio?

Key takeaways

  • We can automate publishing a subgraph to the registry inside our CD pipeline using the rover subgraph publish command.
  • 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.

Up next

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.

Previous
Next