The build failed because a table needed a new column. The error was small, but it stopped everything. You could add it in the database by hand, but then the schema drifts. The fix must be in code, tracked, repeatable.
A new column is the simplest schema change, yet it’s where migrations go wrong. You run ALTER TABLE in production without a rollback plan. You push a migration that locks rows for too long. You forget to set defaults, and the application breaks under nulls you didn’t expect.
Good practice is to create the new column in a safe, non-blocking migration. Add it first, deploy code that starts writing to it, then backfill slowly. Only after data is complete should you make it required. This sequence prevents downtime and avoids race conditions between deploys.
When naming the new column, avoid collisions with reserved words. Keep names exact and predictable for both queries and ORM mappings. Document why it exists and the data it stores. If the column represents a new capability, think through indexing strategy. Adding an index with the column later reduces the risk of long locks.