3 ms·
I have to point out, it seems, that you don't change your database schema "multiple times a day". Nor is every database schema linked to downtime (especially if
by slver 5y ago
I have to point out, it seems, that you don't change your database schema "multiple times a day". Nor is every database schema linked to downtime (especially if you follow service/module orientation with distinct aggregates, and don't throw everything in one shared database like it's the 90s). Most updates don't need downtime. Few rare ones, do, unless you want major complications.
The irony you point out, isn't a huge irony. When your business is small, downtime is fine. As you grow and it becomes "not fine" you have people around the world that can handle it off-peak hours for the users during dev work hours.
- rtpg 5y agoSorry, I guess the rationale here is more that DB schema changes (at least for most "basic" web applications) go through the same codebase as normal application changes, so it's in the same pipeline of changes as other changes. By asking for changes to be done in a highly-available way, you reduce coordination efforts needed for release. "Our main branch is always deployable" is a great default! And while actualy DB schema changes aren't multiple times a day, even on a relatively small team simple DB changes come into the pipeline once a week? Most aren't backwards-incompatible, but the beauty of it is that we don't even have to consider that much, because of this strategy. Maybe the "no downtime" stuff is unreasonable. In my case, we are a relatively small team servicing a good amount of customers (who do time-sensitive work), so the effort here is worth it. But if you can get away with it (with downtime windows being big enough to recover from issues), then it's definitely gonna be easier.