Skip to content

ops: database migrations with a tested rollback path #61

Description

@joelpeace48-cell

Problem

Once a database exists, schema changes need to be reproducible across
development, staging, and production. Ad-hoc SQL applied by hand diverges
between environments, and the divergence is usually discovered during an
incident.

What to do

  • Versioned migration files committed to the repository, applied in order.
  • Migrations run as an explicit deploy step, not automatically at application
    boot — concurrent instances racing to migrate is a real failure mode.
  • Every migration reversible, with the down path actually exercised in CI
    rather than assumed.
  • Expand-contract for breaking changes: add the new column, backfill, switch
    reads, then drop the old one in a later release. Never in one step.
  • Test migrations against a realistically sized dataset — a migration that
    takes eight hours and locks a table is a different problem than one that runs
    in a second.

Acceptance criteria

  • Versioned, ordered migrations committed
  • Applied as a deploy step, not at boot
  • Down migrations exercised in CI
  • Expand-contract documented as the required pattern
  • Timing measured against realistic data volume

Notes

Exercising the down path in CI is the part teams skip, and it is the part that
matters at 3am.

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSThird CampaignCampaign: Third Campaignarea:opsDeploy, observability, CIdifficulty:mediumFamiliar patterns; touches a few files or conceptspriority:highNeeded for the next milestonetype:choreTooling, CI, dependencies

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions