You've got more than one app sharing a db when you deploy a new version. Unless you're happy with downtime during deploys as the cost of not having to manage how your schema evolves.
These kinds of best practices make sense regardless of how many apps access a db.
Following the advice doesn't also prevent you from enforcing a strict contract for external access and modification of the data.
> You've got more than one app sharing a db when you deploy a new version. Unless you're happy with downtime during deploys as the cost of not having to manage how your schema evolves.
2 deploys is all it takes to solve this problem.
* 1 to deploy the new schema for the new version.
* 1 to remove the old schema.
This sort of "tick tock" pattern for removing stuff is common sense. Be it a database or a rest API, the first step is to grow with a new one and the second is to kill the old one which allows destructive schema actions without downtime.
2 deploys isn't enough for robustness. It depends on what the change is, but the full sequence is often more like
* Add the new schema
* Write to both the new and old schemas, keep reading from the old one (can be combined with the previous step if you're using something like Flyway)
* Backfill the new schema; if there are conflicts, prefer the data from the old schema
* Keep writing to both schemas, but switch to reading from the new one (can often be combined with the previous step)
* Stop writing to the old schema
* Remove the old schema
Leave out any one of those steps and you can hit situations where it's possible to lose data that's written while the new code is rolling out. Though again, it depends on the change; if you're, say, dropping a column that no client ever reads or writes, obviously it gets simpler.
Yup, it depends on the change. Sometimes two deploys is enough — e.g. making a non-nullable column nullable — and sometimes you need a more involved process (e.g. backfilling).
Nonetheless, I agree with the OP that the article's advice is pretty bad. If you ensure that multiple apps/services aren't sharing the same DB tables, refactoring your schema to better support business needs or reduce tech debt is
a. tractable, and
b. good.
The rules from the article make sense if you have a bunch of different apps and services sharing a database + schema, especially if the apps/services are maintained by different teams. But... you really just shouldn't put yourself in that situation in the first place. Share data via APIs, not by direct access to the same tables.
Why wouldn't one deploy be enough to convert a non-nullable column to nullable? Going the other way takes two deploys I can see, but this way seems like is entirely backwards compatible.
If apps are using the column they might need code changes to handle the column suddenly having nulls. So you would have to change and redeploy the code, then make the column nullable.
These kinds of best practices make sense regardless of how many apps access a db.
Following the advice doesn't also prevent you from enforcing a strict contract for external access and modification of the data.