Questions
4 of 5
How do you handle database schema migrations in a Go project CI/CD pipeline?
Difficulty: 7/10
migration tooling, CI/CD integration, zero-downtime deployments
Version SQL migration files in source control using golang-migrate or goose, run migrations as a CI step against a test database, and deploy destructive changes with multi-phase migrations.
golang-migrate setup
CI/CD migration strategy
- 1
CI: run migrations against a fresh test DB, run integration tests, then merge
- 2
Production: run migrations as a Kubernetes Job or init container before rolling deployment
- 3
Backward-compatible migrations: add columns as nullable first, backfill, then add NOT NULL constraint
- 4
Never DROP COLUMN in the same deployment that removes the code referencing it — two-phase deploy
- 5
Use advisory locks (SELECT pg_advisory_lock) to prevent concurrent migration runs
Scenario Questions
0-2 years experience
- 1We have a Go microservice that uses PostgreSQL. How would you add a new column to an existing table as part of a CI pipeline without breaking the current deployment?
- 2If a migration script fails during the CI run, what steps would you take to ensure the pipeline reports the failure and the database is left in a consistent state?
2-5 years experience
- 1During a release we noticed that a recent migration caused a runtime panic in our Go service. Walk me through how you would investigate and fix the issue.
- 2Explain the pros and cons of using a tool like golang-migrate versus embedding raw SQL files in your repository for managing migrations in CI/CD.
5-8 years experience
- 1Our service runs zero‑downtime deployments across multiple regions. How would you design the migration strategy in the CI/CD pipeline to guarantee no downtime and handle rollbacks if something goes wrong?
- 2What considerations would you make for handling large data backfills in migrations to avoid performance impact on production, especially when the CI pipeline triggers them automatically?
8+ years experience
- 1We have several Go services sharing a monolithic database, each with its own CI pipeline. How would you coordinate schema migrations across services to avoid coupling and ensure safe, incremental releases?
- 2Describe a long‑term strategy for evolving the database schema in a microservices architecture where some services will eventually own their own databases, and how CI/CD pipelines should adapt during that transition.
Follow-up Questions
- Can you walk me through how you test a migration locally before it reaches CI?
- What metrics or alerts would you put in place to catch migration‑related issues in production?
- Give an example of a migration that required a data transformation and how you handled it.