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 .

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 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 only tracked the production version of the graph (the current ). Earlier in the course, we added a staging to the to correspond to the staging environment of our . Let's make sure to update our CD workflow!

After deploying to the staging environment, we'll publish our changes to the staging of our , which will trigger a . 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 to the staging in the schema registry.

This job uses the rover subgraph publish command behind the scenes to publish the schema changes to the relevant in .

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 's repository.

This triggers the Staging Deploy job to deploy the changes to the Heroku app for the listings '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 to the staging on .

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 .

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

What happens after a schema is published to the registry? A starts! We can see the steps in the launch process in the Launches page of Studio, making sure we have the staging of our selected.

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

We can see that Launch Sequence section for this specific 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 are available in Airlock's staging environment. Teammates and other stakeholders can use the Apollo Explorer to test out the new 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 to our graph's current . This initiates a new , 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 GraphOS?

Key takeaways

  • We can automate publishing a to the registry inside our CD pipeline using the rover subgraph publish command.
  • Publishing a to any in the registry triggers a . We can view the launch sequence in the Launches page of 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

Share your questions and comments about this lesson

Your feedback helps us improve! If you're stuck or confused, let us know and we'll help you out. All comments are public and must follow the Apollo Code of Conduct. Note that comments that have been resolved or addressed may be removed.

You'll need a GitHub account to post below. Don't have one? Post in our Odyssey forum instead.