How I created a CD pipeline for Firebase RemoteConfig using GitHub actions

Photo by Quinten de Graaf on Unsplash

Firebase Remote Config is a service that lets you change the data that your web/mobile application uses without the need for a new deployment. This service can also help with A/B testing which is another really useful service provided by firebase.

Firebase Remote Config console allows you to edit and publish variables through an intuitive UI. It also allows you to update these variables through a REST API. I wanted to create a solution that had the following properties -

1. Other developers are able to push updates to remote config through a CI/CD system based on git
2. Avoid having to manage users through google cloud IAM
3. Update a google sheet, every time new updates are pushed to the firebase remote config

I've documented the steps that you may need to follow to set up a similar CI/CD pipeline for your remote config workflow. As of the writing of this post, Firebase CLI does not support the deployment of remote-config values. The same architecture can be extended to any other firebase service that does not have native CLI support.

Setup

Setting up the admin account credentials

In order to set up a continuous deployment pipeline, you'll need a service account key from the Firebase Console. This is how it can be obtained. Navigate to Settings -> Project Settings -> Service accounts. Select "Generate new private key" to generate a private key for the next steps.

Note: This key enables access to your firebase project. Do not share this key or directly add it to your version control. We'll look at a way to securely use this key from our CD pipeline, in the next steps.

Setting up your repository

I've added the starter code in this github gist. The repository can be set up with a virtual environment and the dependencies can be installed with

pip install -r requirements.txt

Let's try a local deployment first

The code uses two environment variables for programmatically interacting with firebase. They are

1. PROJECT_ID
2. CREDENTIALS

The PROJECT_ID points to your firebase project. The same can be exported with

export PROJECT_ID=<your-firebase-project-id>

The CREDENTIALS variable needs to contain the information that's present in the json file containing your service account details. The same can be exported to your shell using

export CREDENTIALS=$(cat service-account.json) 

In order to test whether the service account credentials have been properly exported, you can print the CREDENTIALS variable with echo CREDENTIALS and confirm that the contents of the service account json file are indeed present in the variable.

With our environment variables set up, we can now test whether we're able to make authenticated API calls to Firebase Remote Config. From your shell, running the following command should work without any errors

python remote_config_manager.py --action=versions

Now, you have the ability to interact with Firebase Remote Config REST API.

Creating your remote config variables

The remote config variables can be added in remoteconfig.template.json or any other file that you reference in the _publish method of the code. The key thing to note here is that this file will be responsible for all the variables you store and update in remote config. This is where a logic can be written to update the most-recent value in google sheets or any other system for better accessibility/visibility.

Setting up the continuous deployment pipeline

In order to set up a CD pipeline on GitHub, we'll store our PROJECT_ID and CREDENTIALS as repository secrets. For this, we'll navigate to settings in our GitHub repository and add the two values in the secrets section. This is what the end result should look like.

After setting up the secrets for your pipeline, all we're left to do is to set up our workflow using the cd.yaml file. This file will need to be present at ./github/workflows/ in your repository in order to GitHub to trigger this as a GitHub action.

After this, the following will happen -

1. Every commit will trigger the build step. This is where additional steps of json validation can be added.
2. Every commit to the main branch (from a PR or otherwise) will result in the values present at remoteconfig.template.json being deployed directly to your project's remote config. You may wish to setup notifications regarding informing you of updates. You may also want to disable direct push to the main branch to avoid accidents.

Summary

In this post I've summarised how I created a CD pipeline for Firebase Remote Config in order to save up on my time and to enable git based version control for my remote config values. I found using GitHub Actions really intuitive and the build & deploy process was very fast, especially with dependency caching. Maybe I'll explore GitHub Actions for more use cases going forward with my projects.

Comments

[Sebastian Jimenez V.]

hey @anshaj thanks for sharing pretty nice write up! I'm looking for feedback on my project, I want to make the best remote config tool there is, and I would love it if you could share what would be something or some things that you'd definitely want to see in a new remote config tool! If you're interested in getting early access to the beta, here the link! tower.rocktlab.com

[fe-data]

Great example! Got is almost working. What is the format of 'remoteconfig.template.json'