Ideal place/point in time to run migrate?

[SHxKM]

If I'm deploying on Railway, I need a way to run migrate during the build process. I'm currently pointing Railway to an adjusted Dockerfile (they don't support docker-compose fully yet), and have the following in docker-entrypoint-web:

#!/usr/bin/env bash

set -e

# Always keep this here as it ensures your latest built assets make their way
# into your volume persisted public directory.
cp -r /public_collected /app

# ADDITION 👉 Apply database migrations
echo "Apply database migrations"
python manage.py migrate

exec "$@"

However, this makes tasks like ./run deps:install fail because they try to acquire a connection to the database to perform this action.

Any ideas where I can incorporate this?

[nickjj]

Hi,

I treat migrations as a separate deploy step that's agnostic to how the app is deployed.

Ultimately the use case is to run a migration before the new version of your application goes live.

• With self hosting and Docker Compose you can run ./run manage migrate before you docker compose up
• With Kubernetes, you can use Helm or Argo CD to run it in hook that happens before your main app deployment gets deployed

I never used Railway but I'm guessing they have a way to run any arbitrary commands before or after a release goes out?

I like this strategy because running it in an entrypoint has implications when you want to horizontally scale your app and you have 10 copies of your app all running the migrate command. Technically migrations are idempotent but there's still benefits to have an application deployment get blocked from being deployed because a previous unrelated step (running a migration) failed. Separation of concerns.