How do you test a schema change against the previous release?
by•
A migration can pass with the new build and still break a worker from the previous release that's finishing a queued job. Rename a column in one deploy, and that worker may keep writing the old name after the database has moved on.
Adding the new field first lets both versions coexist. Then you can backfill, switch reads, and remove the old field in a later deploy. The dangerous bit is declaring the old writers gone too early.
What do you check before that cleanup: running worker versions, drained queues, or logs showing no writes to the old field? If you run a small team, what's the smallest check you'd trust?
6 views
Replies
Small team here too. Our rule is that the migration goes out before the code and only adds things, so the old build keeps working against the new schema. Before any DB change we take a pg_dump and make sure it actually wrote. For the cleanup, I'd trust the logs on the real server over any guess that the old workers are gone. If nothing has written to the old field there, it can go.
On mobile the old writers never fully drain, which changes the answer. My app's store builds lag the backend, and some people never update, so I treat the previous release as a client that lives forever. The rules I follow: a new parameter that is absent means the old behaviour, new error codes get mapped back to ones the old app understands, and the additive part (new rules, a new function) is deployed first, the changed one after. Then I probe the changed endpoint with an unauthenticated call and read the logs. For removing an old field, the smallest check I would trust is the same as yours, logs showing no reads or writes of it, but on mobile I would add one more: the oldest app version still opening the app.