Motivation

Database migrations are an essential component in the life cycle of any relational database. We needed a way to trigger database migrations in our development and production environments within our existing CI/CD pipelines running in GitHub Actions.

We wanted to avoid provisioning separate compute for handling the migrations, and minimize the risk of errors due to duplicated code, environment variables, or containers.

Process

At a high level, the process we settled on for triggering our migrations is as follows. Within a CD pipeline:

1. Deploy the latest version of our API, which includes an ORM and migrations to run.
2. Have an endpoint in the deployed API that can execute migrations. This eliminates the need to create or manage different compute to run the migration.
3. Send an HTTP request to the migration endpoint that actually runs the migration.

Our Stack

This logic can be employed with any number of API/ORM/CD Pipeline stacks. For the remainder of this post, we will be working through the logic with the following stack:

1. API: Flask
2. ORM: flask_sql_alchemy + Flask-Migrate
3. CD Pipeline: GitHub Actions
4. Cloud Infrastructure: Google Artifact Registry and Google Cloud Run

Implementation

First we created the API endpoint that runs the migrations. One thing to note is how authentication is handled. For this, we add a function decorator that checks to ensure the header passed to the request has an “admin” token. This “admin” token is stored as an environment variable on the API’s compute instance and as a GitHub Actions secret.