Might be the case. Alternatively, you’re solving for a different use case.
Most of the web development needs zero-downtime deployments. This means that:
- There is a time window during the deployment when the old version and the new version of the app are running at the same time,
- The old version of the app must work with the migrated schema/data.
Let’s consider a common relational DB schema migration: adding a column to a table. Let’s say the migration failed.
Your approach seems to be suggesting that the app should still boot and run just fine. How am I supposed to write the app to use the new column since it might not be there if the migration failed?
I choose to avoid that problem (and the effort to somehow solve it) altogether by not booting the new version of the app, aborting the deployment process and letting the old version run. You might not have that convenience, but most of microservices do, so I see no reason not to take advantage of it.
There’s not much babysitting, since the migrations are run automatically as part of the deployment. Whether this is a separate process or happens in the app doesn’t really matter. The key is to abort the app boot on failed migrations.
