Deploying Firebase task worker to Google Cloud Platform with Gitlab CI

This is a continuation of my previous article that was explaining about how a server worker can fit into your Firebase application family. In this article I will walk you through how you can get it all set up and deploy your NodeJS worker to Google App Engine Flexible Environment.

Make sure that you have read the article below to get an understanding of why I am making a case for putting in Google Cloud Platform into the mix.

Making a Firebase server worker in the cloud

Before reading any further, you should be fairly comfortable with the concept of continuous integration to fully appreciate the article. I will go through some tips and tricks that I think are good practices and how to set up a flow that allows you to jump directly from pushing the code to Gitlab and going straight to see the updated application in the Cloud Console, without executing a single command apart from git commit and push.

Let’s jump into it!

This is what your Gitlab continuous integration configuration file will look like when we’re done.

If you think that parts of the code look familiar, it might be that you have read any of my previous articles about Gitlab continuous integration for Google App Engine or Firebase. This project is utilizing parts of both those articles in one and the same configuration file.

First, the elephant in the room

There is no “testing stage” in the example above . That step should go first of all and if that step fails, the subsequent deployment steps will not be executed. This is how your file actually should look like.

stages:
  - test
  - firebase_deploy
  - gcp_deploy

Secondly, deploy Firebase

In my case, the NodeJS worker does not provide any external access at all apart from the data that it can read from the Firebase database. The server worker does not offer any API request endpoints or similar. It’s a confined worker that only reacts to the data that is passing through its event listeners.

The NodeJS worker is in fact only using the database part of the Firebase suite. So I have chosen to maintain the database definition rules in this project. The firebase.json configuration file is as simple and short as this:

{
  "database": {
    "rules": "rules.database.json"
  }
}

Deploy the Firebase database rules first to make sure that the application instance is not running any new code that is depending on any potential new rules. If there are non-backward compatible changes, then you should of course account for that and take appropriate actions to make sure that your old app code isn’t doing something strange with your new data structures or rules.

Lastly, deploy the worker to GCP

This is the final step: to deploy the NodeJS application to Google App Engine Flexible Environment.

N.B. At the time of writing, the GAE Flexible environment is still in Beta and should be used with care, i.e. not in production.

But since I know what I’m doing (famous last words), I am having “production configuration” in this example anyway 😎

Starting from the bottom, we’ll first use the Gitlab project variables and pipe them into files that we’ll be needing. In this case you can see that I am having a file called “service-account.json” which is used for service account access to my Firebase application.

Pay attention to that the PROJECT_ID variable is being set according to the different project names in the different build types for master and develop branch.

After that, let’s jump to the job template to see the most interesting part of the script.

Everything under “before_script” should be self-explanatory if you have read my previous article about GAE deployment with Gitlab. So let’s focus on the “after_script” parts.

Cleaning up previous versions

Make sure that you keep your app versions and services cleaned up in the dashboard. You could automate the deletion process with some scripting magic, but it might or might not be a good idea, depending on the flow and level of control that you want when maintaining your application. I would say that you probably know which way to go if you’re reading this. Just know that you can run into a “max versions” error if you’re not keeping it clean.

Maximum number of env:flex versions exceeded

Push the code to Google Cloud Repository

I find it convenient to also automate the distribution of the code to the Google Cloud Repository at the same time as deploying the application. This will allow you to debug your application with the same code base as you deployed.

Deploy the new version

The last line is simply just deploying the application and setting a version number that is linked back to the Gitlab CI pipeline in which it was deployed from.

gcloud --quiet --project $PROJECT_ID app deploy --version pipeline$CI_PIPELINE_ID

The pipeline numbers are ever increasing and unique (at least for your project) which makes them good version numbers that can be ordered chronologically.

Now, scrolling up to the very beginning, it should be possible to just copy/paste the .gitlab-ci.yml script and make it work with very little modifications.

Q.E.D.