4 ms·

One of the biggest problems I have is that I'll branch out to a new feature branch, modify (add/rename columns) in the db, then get sidetracked by something whe

One of the biggest problems I have is that I'll branch out to a new feature branch, modify (add/rename columns) in the db, then get sidetracked by something where I have to switch back to master, making everything explode because the db is still modified, while my application is calling the old values. I'd love it if they found a way to link up your database to a repo, so that it could track/rollback changes easily as switching branches (I guess an sqlite db might work, but it's not perfect)

nlh 14y ago
It's a great idea and something that even I, humble amateur developer, have encountered (and wanted). Any thoughts about which DB would be best suited for this? I wonder if it could be integrated with git somehow and make the whole process seamless.
- viaken 14y ago
  You could certainly use SQLite this way, as long as you don't need anything hefty. Add and commit your db file, then fork and modify as needed.
atomical 14y ago
I would disagree with this strategy as it adds more complexity than the original problem. It's much easier to rollback the migrations on the feature branch and switch to master. Avoiding situations like this is the best policy though as unexpected things will happen and you can be less sure that things are working properly.
- eggbrain 14y ago
  "Avoiding situations like this is the best policy though as unexpected things will happen" Yes, but they happen. This seems like replying to someone drowning "well, you should have avoided swimming!" You also make the assumption that we are using Rails (or some framework with migration support) -- many people won't have that luxury. Finally, while the setup might be challenging (as in, figuring out a way to implement db tracking in git), I find it very curious that it would be much easier in anyones mind to do two tasks, doing all the rollbacks and switching branches, vs just switching the branch.
  - mhitza 14y ago
    I'll start hacking on that. Now to keep this comment, if it ever comes to happen, I'll notify you :)
  - atomical 14y ago
    This isn't a setup issue. Don't work on more than one branch/feature at a time. It's a bad idea and not conducive to getting shit done.
    - eggbrain 14y ago
      Git checkout -b "feature-1" Git commit -am "Added feature 1, which included a migration" Git checkout -b "feature-2-that-builds-off-feature-1" Git commit -am "Added feature 2, which includes another migration" Git checkout master Broken (and with multiple migration files, even though I branched off for each new feature.)
      - grey-area 14y ago
        Have you considered branching the database along with your code?
    - samspot 14y ago
      You act like we have a choice in the matter. "Sorry, I can't look into your emergency production problem, I'm adding features to a blog."
robertfw 14y ago
One approach is to use multiple local databases, one for each schema in use. When you switch branches, update your app config to point at the appropriate database. It's not perfect and we still have to do work keeping in sync within our team, but it does the job locally.
deleted 14y ago
[deleted]
wahnfrieden 14y ago
You're using branches in production? Consider not doing that.
- eggbrain 14y ago
  Who said anything about production? Are you saying you've never hit a snag with a local db that had data that would be a pain to re-import?
  - wahnfrieden 14y ago
    Consider forgoing long-lived/significant local branches too then. Branching has its downsides, and avoiding it has some upsides particularly for small teams. As an alternative, you might start using feature flags instead. Look into "continuous deployment" as well for more insight.
  - grey-area 14y ago
    Keep your database config for the app in version control with the code, and change to another database per branch. This means your data in that db will diverge from the main branch slightly, but if that is too much of a problem and you need constant updates from live, you could look into migrations like those used by rails, which store your db changes so that they can be replayed on top of newer data from master and bring it up to the new schema. It's quite easy to setup a bare bones migration system using plain SQL migration files and some scripts if this is a problem you see often. I often work with several branches of code in rails, and it's not a big problem, you just need a system for keeping the data in sync with the code.
- thibaut_barrere 14y ago
  It's fairly common and works pretty well if you have a good test coverage and monitoring in place. GitHub is a documented example (and I happen to deploy branches daily too :-): https://github.com/blog/1241-deploying-at-github https://github.com/blog/1241-deploying-at-github
  - amatix 14y ago
mamcx 14y ago
Perhaps having a DB.sql script, plus a data generator and/or a dump of the data before doing the branch plus auto-create & load the data when switch. Yep, look like not as easy I think at the start of the reply...
thibaut_barrere 14y ago
This has been around in Rails since 2008 using ERB: http://mislav.uniqpath.com/rails/branching-the-database-along-with-your-code/ http://mislav.uniqpath.com/rails/branching-the-database-alon... This way you can enable a branch-specific database (if needed) and switch back and forth during the day if you need it. One could somehow easily adapt that for another development framework, though!
ubercore 14y ago
We've been using a db-follows-branch system with Fabric. Devs can run "fab update_db" to get a new dump of production-based testing data, and create a database named after the current branch. Still a bit manual, but it really helps in situations like that.

nlh 14y ago

It's a great idea and something that even I, humble amateur developer, have encountered (and wanted). Any thoughts about which DB would be best suited for this? I wonder if it could be integrated with git somehow and make the whole process seamless.

viaken 14y ago
You could certainly use SQLite this way, as long as you don't need anything hefty. Add and commit your db file, then fork and modify as needed.

atomical 14y ago

I would disagree with this strategy as it adds more complexity than the original problem. It's much easier to rollback the migrations on the feature branch and switch to master. Avoiding situations like this is the best policy though as unexpected things will happen and you can be less sure that things are working properly.

eggbrain 14y ago
"Avoiding situations like this is the best policy though as unexpected things will happen" Yes, but they happen. This seems like replying to someone drowning "well, you should have avoided swimming!" You also make the assumption that we are using Rails (or some framework with migration support) -- many people won't have that luxury. Finally, while the setup might be challenging (as in, figuring out a way to implement db tracking in git), I find it very curious that it would be much easier in anyones mind to do two tasks, doing all the rollbacks and switching branches, vs just switching the branch.
- mhitza 14y ago
  I'll start hacking on that. Now to keep this comment, if it ever comes to happen, I'll notify you :)
- atomical 14y ago
  This isn't a setup issue. Don't work on more than one branch/feature at a time. It's a bad idea and not conducive to getting shit done.
  - eggbrain 14y ago
    Git checkout -b "feature-1" Git commit -am "Added feature 1, which included a migration" Git checkout -b "feature-2-that-builds-off-feature-1" Git commit -am "Added feature 2, which includes another migration" Git checkout master Broken (and with multiple migration files, even though I branched off for each new feature.)
    - grey-area 14y ago
      Have you considered branching the database along with your code?
  - samspot 14y ago
    You act like we have a choice in the matter. "Sorry, I can't look into your emergency production problem, I'm adding features to a blog."

robertfw 14y ago

One approach is to use multiple local databases, one for each schema in use. When you switch branches, update your app config to point at the appropriate database. It's not perfect and we still have to do work keeping in sync within our team, but it does the job locally.

deleted 14y ago

[deleted]

wahnfrieden 14y ago

You're using branches in production? Consider not doing that.

eggbrain 14y ago
Who said anything about production? Are you saying you've never hit a snag with a local db that had data that would be a pain to re-import?
- wahnfrieden 14y ago
  Consider forgoing long-lived/significant local branches too then. Branching has its downsides, and avoiding it has some upsides particularly for small teams. As an alternative, you might start using feature flags instead. Look into "continuous deployment" as well for more insight.
- grey-area 14y ago
  Keep your database config for the app in version control with the code, and change to another database per branch. This means your data in that db will diverge from the main branch slightly, but if that is too much of a problem and you need constant updates from live, you could look into migrations like those used by rails, which store your db changes so that they can be replayed on top of newer data from master and bring it up to the new schema. It's quite easy to setup a bare bones migration system using plain SQL migration files and some scripts if this is a problem you see often. I often work with several branches of code in rails, and it's not a big problem, you just need a system for keeping the data in sync with the code.
thibaut_barrere 14y ago
It's fairly common and works pretty well if you have a good test coverage and monitoring in place. GitHub is a documented example (and I happen to deploy branches daily too :-): https://github.com/blog/1241-deploying-at-github https://github.com/blog/1241-deploying-at-github
- amatix 14y ago

mamcx 14y ago

Perhaps having a DB.sql script, plus a data generator and/or a dump of the data before doing the branch plus auto-create & load the data when switch. Yep, look like not as easy I think at the start of the reply...

thibaut_barrere 14y ago

This has been around in Rails since 2008 using ERB: http://mislav.uniqpath.com/rails/branching-the-database-along-with-your-code/ http://mislav.uniqpath.com/rails/branching-the-database-alon... This way you can enable a branch-specific database (if needed) and switch back and forth during the day if you need it. One could somehow easily adapt that for another development framework, though!

ubercore 14y ago

We've been using a db-follows-branch system with Fabric. Devs can run "fab update_db" to get a new dump of production-based testing data, and create a database named after the current branch. Still a bit manual, but it really helps in situations like that.