And this is for a dead simple little setting.
Put bagel in toaster.
Update the db model.
Add a migration.
Update the viewmodel <==> db model translation in relevant requests.
Get bagel and butter it.
Commit.
Test the migration on a staging db if feeling paranoid, cause it's just adding a column.
Push to master.
Update production.
Take last bite of bagel.
If you aren't also doing the frontend, tell the guy who is to check out the updated swagger docs.
We're also not doing the common website/webapp thing, but rather on-premise enterprise software. So we have to update installers too, and be relatively paranoid about updates, because it is intensely painful when we have a bad update with one of our customers.
On our less important software that'd just be a direct push to production though.
This kind of mentality is why most applications are shit and broken. And why most hires are worthless.
And everyone is not working on a cookie cutter over-bloated rails website. Sorry but this kind of remark simplifying our job always pisses me off.
In a system of any complexity, changing your data model is an activity that requires due diligence to mitigate any downstream risk.
We also have throwaway apps like an internal time clock system which monitors when people show up based on their cell MAC.
Latter case: Adding a checkbox is easy.
Former case: Adding a checkbox is easy but we have to test it first.
That sounds miserable.
We started adding in other employees in multiple departments cause they liked it better than manually tracking.
When your tables have millions of records for enterprise customers, it's significantly more involved than you describe
Once your application reaches a certain scale there is a huge chance that generated migration could lock a table for minutes to hours which isn't acceptable.
We allow developers to run generated migrations in dev/testing environments but when its time to go to staging we evaluate the changes made and check query plans and figure out what type of locking is going to happen and how long it would take it prod. There is very few times the migrations Django or Rails generate are acceptable at our scale in production.
For our large scale applications we back up the database and have required down time from our customers while doing a major migration.
Everything isn't always simple. But adding a check box in 90% of cases usually is.
Now lets say you are doing 15,000 requests per second on that table.... is preventing those from executing acceptable in your system? Its not in mine which is why we don't run ORM generated migrations.
You monster. You fucking monster.
The reality is that ORMs are a huge headache and a chunk of dependency and magic that make some people uncomfortable. Even though I make more mistakes writing the glue code between SQL and my backend than I would with the ORM, I know how every bit of that code works, and I've reduced significantly the magic I have to deal with in order for my code to work (basically, just the database driver since I own everything else).
ORMs are a huge surface to secure, tune, and understand, and I think that it's unfair to tell someone their app sucks just because they refuse to use one.
But seriously. Pushing to master, AND updating production...where are your unit tests!?!?