How do you handle database schema migrations in a Go project CI/CD pipeline?

Question

Accepted Answer

// Migration files — named sequentially
// migrations/
//   000001_create_users.up.sql
//   000001_create_users.down.sql
//   000002_add_profile_table.up.sql
//   000002_add_profile_table.down.sql

// 000001_create_users.up.sql
// CREATE TABLE users (
//     id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
//     name TEXT NOT NULL,
//     email TEXT UNIQUE NOT NULL,
//     created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
// );

// Run migrations at service startup (simple services)
func runMigrations(db *sql.DB) error {
    driver, err := postgres.WithInstance(db, &postgres.Config{})
    if err != nil { return err }
    m, err := migrate.NewWithDatabaseInstance(
        "file://migrations", "postgres", driver,
    )
    if err != nil { return err }
    if err := m.Up(); err != nil && err != migrate.ErrNoChange {
        return fmt.Errorf("migration failed: %w", err)
    }
    return nil
}

// Or run as a Kubernetes Job before deployment
// spec:
//   initContainers:
//   - name: migrate
//     image: myservice:latest
//     command: ["/migrate", "-path", "/migrations", "up"] CI: run migrations against a fresh test DB, run integration tests, then merge Production: run migrations as a Kubernetes Job or init container before rolling deployment Backward-compatible migrations: add columns as nullable first, backfill, then add NOT NULL constraint Never DROP COLUMN in the same deployment that removes the code referencing it — two-phase deploy Use advisory locks (SELECT pg_advisory_lock) to prevent concurrent migration runs

How do you handle database schema migrations in a Go project CI/CD pipeline?

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.

How do you handle database schema migrations in a Go project CI/CD pipeline?

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.

Scenario Questions

Follow-up Questions