Skip to main content

CI/CD

Build and run a migrator binary from the same source as your application.

go test ./...
go build -o queen-migrate ./cmd/migrate

Run preflight checks:

./queen-migrate check --driver postgres --dsn "$DATABASE_URL" --ci --no-gaps
./queen-migrate plan --driver postgres --dsn "$DATABASE_URL"

Apply:

./queen-migrate up --driver postgres --dsn "$DATABASE_URL" --yes
./queen-migrate status --driver postgres --dsn "$DATABASE_URL"

Rollback testing​

Use a disposable test database:

./queen-migrate check \
  --driver postgres \
  --dsn "$TEST_DATABASE_URL" \
  --rollback-test

--rollback-test applies all migrations, resets them, and applies them again. It refuses to run against a database that already has applied migrations.

Deployment shape​

Good production shapes:

  • one Kubernetes Job before app rollout;
  • one CI/CD migration step before deploy;
  • one release image command such as /app/migrate up --yes;
  • local developer runs through go run ./cmd/migrate.

Keep exactly one intentional migrator job active per environment. PostgreSQL locking protects against accidental overlap, but deployment should still model migrations as a single step.

For more complete release recipes, see Workflows.