#release-engineering (2024-02)
All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.
CI/CD Discussions
Archive: https://archive.sweetops.com/release-engineering/
2024-02-07
Here’s one, for you release-engineering types. What’s the approach that most folks take these days for handling db migrations. Laravel, or whatever. Do folks tightly couple the migrations with the application, applying them at the time of app code deploy? I still see this frequently, and it seems aweful. My answer is the same as always – to manage the DB schema/queries/etc., as their own versioned products. This way if you know your app is going to need a new column you can make that change before the app is deployed. As you would do with any dependency. LMK, I’m interested in finding out what others see/do.
tight coupling of db migrations seems to be the (outdated) norm. Prefer indeed the forward compatible approach that version x of teh app can work with version x+1 of the db scheme. (eg not using select * but column names, doing some temp aliases/views). Bigger changes need to have a bit more braincells involved upfront though
Brainsells are out of scope. :)
Thanks, just making sure I wasn’t missing some reason to do it like it’s 2012. :)
As a software engineer I like the idea of separating concerns and decoupling things that don’t necessarily need to be together. But TBH I don’t see too much benefit here.
You said “This way if you know your app is going to need a new column you can make that change before the app is deployed”, I don’t see why you couldn’t do this with migrations and the app being together?
There are also cases where the migrations are generated based on the business logic / entities in the app. In that case I would need an extra step of generating migrations in one place, then moving them to another place.
it all depends on use cases. But being able to perform these steps separately has many operational benefits.
There are a lot of arguments for both postures. For me, coming from micro/distributed services shops that have that as a mindset, bolting laravel migrations onto application deployment activities seems awful from beginning to end. For devs/anyone who’s never deconstructed a monolith, it’s a radical idea they can’t quite grasp because their mind is missing that wiring…
I’ll tell ya, as a young lad –with a wild artistic streak– I used to hate it when someone would come tell me how it should be done, but now that I’m the guy watching people flail while setting themselves on fire, I get it.
From what I see in the industry, devs run migrations as a deployment part, usually in order db migration before deployment.
I saw the recommendation to use forward compatible approach and invert that order - deploy and then run the migration
The pattern guarantees that version X works with schema from version X-1.
I like that idea but have not succeeded in convincing dev teams to do that on practice
Yes, it’s hard convincing folks of some things. It’s tough when shops don’t take an ops-first approach. But with app teams being responsible for their own muck ups, it’s on them.