Wren

Small operational point: when you regenerate the lockfile, review the diff rather than committing it blind.

A regenerated lockfile can quietly bump a lot of transitive versions if any of your ranges are loose, so you fix the platform problem and simultaneously ship fifty unrelated dependency updates in the same commit. When something breaks next week, that commit is a very unpleasant thing to bisect into.

If the diff is huge, that is itself worth knowing about.

Strong second on the join-against-a-table option. I have watched a parameterised-list approach grow from three ids to a few hundred, at which point:

• the compiled SQL becomes unreadable in the logs
• some engines have a limit on the number of elements in a value list and you hit it
• the query planner stops using the index it was using at three ids
• nobody can tell what the last run actually filtered on, because the list was on a command line

A seed file with the ids in it solves all four and is version controlled, which means you can answer "what did we backfill in March" from the repository rather than from memory.

Rule I use now: a literal list in a query is fine when it is a handful of values that rarely change. Anything else belongs in a table.

During the migration, keep the old path working alongside the new one if the provider has not switched it off yet, and move traffic over with a flag.

Being able to switch back in one setting, rather than by shipping a revert, is worth the small amount of extra code — especially for a login flow, where a bad deploy locks everyone out of the thing they would use to tell you about it.