What's your team workflow for delivering features that require database migrations. How do you keep migrations from slowing down development as your team grows.
Ask HN: How does your development team handle database migrations?
1–10 of 150 posts
Re: Ask HN: How does your development team handle database migrations?
#2SQL scripts. It is painful.
Re: Ask HN: How does your development team handle database migrations?
#3I've used Flyway[0] at my current and previous shops. It seems to work well.
Re: Ask HN: How does your development team handle database migrations?
#4I've read and reread a great article titled "Evolutionary Database Design" on Martin Fowler's web-site [0]. This article describes database migrations as being a process. We've found that for complex changes, we'll often need a pre-migration and a post-migration (temporally being before the code change and after the code change respectively).
We commit the migrations along-side the application code and in our case we use FlywayDB [1]. The only down-side is that this tool doesn't perform roll-back operations automatically. You can always do them by writing another migration that goes forward to the past.
Another popular DB migration tool is Liquibase [2]. I don't have much experience with this tool as it doesn't fit our build pipe-line as well but it does support and encourage defining a roll-back for each migration.
[0] https://www.martinfowler.com/articles/evodb.html
EDIT: HN is the new StackOverflow? I think this is a really important question for development teams and yet I could see it being closed due to the "Questions asking for tool or library recommendations are off-topic for Stack Overflow ..." rule. Sad!
Re: Ask HN: How does your development team handle database migrations?
#5rails db:migrate
It’s always one of the first things I miss when I have to work on a non-rails codebase.
Re: Ask HN: How does your development team handle database migrations?
#6Migrate during continuous deployment.
We use a staging environment, so CD deployed migrations are always run at least once before running on production.
Migrations have to be written so that currently deployed code will work after the migration. Eg, to rename a column, add+copy, deploy, then in a second migration drop the column.
Re: Ask HN: How does your development team handle database migrations?
#7At my previous job we either didn't migrate and wrote application level transforms that would update records as they were encountered by users (mongodb) or we had a custom built migration system that ran JavaScript snippets on our shards. The migration system was miserable to work with and it was hard to debug the code on stage in such a way that would allow us to anticipate whatever might be on prod...
Re: Ask HN: How does your development team handle database migrations?
#8Re: Ask HN: How does your development team handle database migrations?
#9By hand and with careful consideration. Nope wait we use Alembic. It’s actually pretty good. I like the notion of not doing any data destroying migrations. For example if you are adding a column that replaces a different one keep them both. Then at a later time when no code paths touch the old column and that can be proven drop the column that was deprecated. It’s safer that way. But I’ve not seen this done in practice just something I’ve been thinking about.
Re: Ask HN: How does your development team handle database migrations?
#10At my previous job we either didn't migrate and wrote application level transforms that would update records as they were encountered by users (mongodb) or we had a custom built migration system that ran JavaScript snippets on our shards. The migration system was miserable to work with and it was hard to debug the code on stage in such a way that would allow us to anticipate whatever might be on prod...
This sounds like a nightmare. Why?