In my backend development experience, I've noticed a common issue where database schema designs, migrations, and Docker environment configurations tend to fall out of sync over time. Typically, teams create schemas visually or with SQL, rely on migrations as the true source of truth, and set up Docker environments separately. This separation can lead to reproducibility issues, difficulties in onboarding new team members, inconsistencies across environments, and complications with multi-dialect setups. I'm curious about your team's practices: what do you consider the primary source of truth? Is it just migrations, ORM schema files, reverse-engineered structures from production, or do you prefer an infrastructure-as-code strategy for your database? I'm particularly interested in approaches where the schema structure can reliably generate both SQL commands and Docker configurations. How do mature DevOps teams tackle this challenge at scale?
5 Answers
It's best practice to build and deploy a Docker version alongside code changes, ensuring schema changes are included. I recommend running database migrations as a part of your CI/CD pipeline, ideally ensuring these are backward compatible so existing services aren't impacted during their updates.
Consider using a schema migration tool that integrates with your typical PR processes, like Goose. It can help manage migrations systematically with your code changes, regardless of language.
In my setup, I use schema migration tools like Prisma or Alembic. We bundle migrations as part of our deployment process so they run before the new service version launches, which keeps production as the ultimate source of truth and mitigates drift challenges.
We keep our migrations and schema management in the same Git repository, building from the same commit. That way, if there's a drift issue, we can directly see where things went off track.
To keep everything aligned, it's crucial to apply migrations automatically along with your backend deployments. We usually use tools like Flyway for this. The main idea is to ensure that schema changes are embedded within your migrations and to avoid manual database changes altogether; that way, you eliminate any drift.
Exactly! Relying solely on migrations as the source of truth really helps streamline the process and avoid any unexpected issues.