So we’re all set up with CI/CD that rolls out a shiny new production release to our Firebase hosting every time we merge to master. That’s great.

But it would be really nice to see the production site on a staging environment that’s identical to production, before we decide to make the leap?

It’s a rethorical question… but I am leaning you into a “yes”.

This article will provide you with a Github Actions workflow that helps you replicate production onto a staging project every time you open a Pull Request to mater.

To do this, you will be needing:

1. Firebase token for CI/CD deployment.
2. Service account that can access your Firebase project and storage buckets.

This workflow is assuming that you are making backups as described in previous article. We will be using the snapshot backup in order to replicate the production data into our staging environment.

The reason why we want to replicate the production data, is to make sure that the rollout will behave well once we apply our changes onto production. Our staging environment will be a safety stop to ensure that we capture anything that looked good on development and test data. Because at least in our development environment, data is sometimes not fully as clean and nice as it is on production.

The good thing with this setup is also that it makes a fresh slate out of our staging environment before each review. That means that we can go wild and use the tools in staging to test out and see how it will reflect on our production site, once it is approved.

In one of the steps below, we are copying backup data from production to staging. This is an important step to keep, as Firestore must load its import data from a bucket in the same project.

We are also using the existing snapshot backup, instead of a freshly created one, in order to save some time from our Github Actions billed minutes. The --async export operation in my previous article (about backups) makes the action complete immediately, but it also require us to prepare backups that can be used for later imports (i.e. here). The import operation is also asynchronous, so it will complete right away and save us some minutes of running.

/.github/workflows/restore-staging.yml

This workflow will run and reset your staging environment once you open a pull request from develop branch to master.

You can update the triggering conditions if you have another setup where you have a dedicated staging branch in your repository.