How do you handle database migrations in CI/CD?

Question

Accepted Answer

**Database migrations** (schema changes) are one of the trickiest parts of CI/CD — unlike stateless application code, databases hold **state** that can't simply be replaced or rolled back. Handling migrations carefully (automation, backward compatibility, safe patterns) is essential for reliable deployments.

## Why database migrations are hard

```text
App code is stateless (replace it, roll back freely). DATABASES hold STATE:
  → can't just "roll back" a migration that dropped a column or transformed data
    (the data may be gone) → rollbacks are risky/impossible for destructive changes
  → during deployment, OLD and NEW app code may run SIMULTANEOUSLY (rolling deploy) —
    both must work with the database schema at that moment
→ Schema changes need careful coordination with code deployment.
```

## Automating migrations in the pipeline

```text
→ Migrations defined as CODE (versioned migration files; Flyway, Liquibase, ORM tools)
→ Run migrations as a pipeline STEP (apply pending migrations on deploy)
→ Migrations are versioned and applied in order, idempotently
→ Test migrations in staging before production
```

## Safe migration patterns (backward compatibility)

```text
KEY PRINCIPLE: make migrations BACKWARD-COMPATIBLE so old AND new code both work during
the transition. Use the EXPAND-CONTRACT (parallel change) pattern:
  1. EXPAND → add the new schema (e.g. add a new column) — old code still works
  2. MIGRATE → deploy code that writes to both / reads new; backfill data
  3. CONTRACT → once all code uses the new schema, remove the old (in a LATER deploy)
→ NEVER drop/rename in the same deploy that needs it gone — split across deploys.
→ This enables zero-downtime deploys and safe rollbacks.
```

## Why it matters

Understanding how to handle database migrations in CI/CD is important because **migrations are one of the hardest, riskiest parts of automated deployment**, so it's valuable practical knowledge for reliable delivery.

The core challenge is that, unlike stateless application code (which can be replaced and rolled back freely), **databases hold state** — so a migration that drops a column or transforms data **can't simply be rolled back** (the data may be gone), making destructive changes risky or irreversible, and during rolling deployments **old and new code run simultaneously**, both needing to work with the schema at that moment.

This makes schema changes require careful coordination, unlike the rest of CI/CD.

Understanding how to **automate migrations** (defining them as versioned code via tools like Flyway, Liquibase, or ORM migrations, running them as a pipeline step applied in order and idempotently, and testing in staging first) brings migrations into the automated pipeline safely.

Most importantly, understanding **safe migration patterns** — making migrations **backward-compatible** so old and new code both work during the transition, using the **expand-contract (parallel change) pattern** (expand: add new schema without breaking old code; migrate: transition code and backfill data; contract: remove old schema in a later deploy) and **never dropping/renaming in the same deploy that needs it gone** — is the key skill that enables **zero-downtime deployments and safe rollbacks** despite the stateful nature of databases.

This is genuinely tricky, important real-world knowledge that distinguishes those who can deploy database changes safely from those who cause outages or data loss.

Since database migrations are a hard, risky, unavoidable part of deploying applications with databases, and since handling them carefully (automation plus backward-compatible expand-contract patterns) is essential for reliable, zero-downtime deployments, understanding database migrations in CI/CD is valuable, practically-important knowledge — addressing one of the trickiest aspects of continuous delivery and reflecting the maturity needed to deploy stateful applications safely.