Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you manage your dev database among multiple developers?
8 points by shedd on June 28, 2010 | hide | past | favorite | 7 comments
My co-founder posted this question on Stack Overflow (http://stackoverflow.com/questions/3133639/how-do-you-manage-databases-during-development) and got some good advice. I wanted to get the HN community's take on the question and see if there were any other thoughts:

In your agile startup, how do you handle a multi-person development team where each developer is making changes to the DB schema and everyone needs to have a current copy for local development and testing? What SCM strategies do you use and/or what software to replicate the database? Do you have a central development database?

Thanks for the thoughts!




Database replication will always fail. What you need to do is treat database changes no different that software changes. Developers should make modifications to there local database (they are running local right) and then as they complete their work. The need to script the DDL and DML. This way, the changes can be versioned and applied in sequence to existing environments as well as new environments. The root of all change in a system should always be versioning, to try to manage it any other way is inviting trouble.


My employer uses .NET, but we use the "Rails" model for databases. We have population and migration script directories (for each database) which each contain numbered .sql files. Everything in SVN, update to latest, make your changes, make a migration script, commit script. Repeat.


Clickable link to Stack Overflow question & thoughts:

http://stackoverflow.com/questions/3133639/how-do-you-manage...

plus the other similar thread on Stack Overflow:

http://stackoverflow.com/questions/988426/how-should-you-bui...


I got some good responses when I asked a similar question on SO a long time ago:

http://stackoverflow.com/questions/6371/how-do-you-manage-da...

Bottom line: script all your changes to the DB schema, and check the scripts into version control. If you need mock data, write a script that loads it into the DB, and check that into version control.


One option is to have your code manage the database schema it needs rather than managing the schema externally. You would have some kind of initialization routine that checks the schema and creates anything that it needs. This probably makes a little more sense if you are using some kind of OR mapping scheme so you don't have to duplicate data (some OR mapping tools can do this for you).


Liquibase:

http://www.liquibase.org/

The contents of our personal development databases are not synchronized, just the schema. Each developer has enough mock data to run our app for development purposes.

At a previous job, all developers shared a single development database. It was a huge pain, and I don't recommend that practice.


Thanks for the link - interesting - Liquibase seems very much oriented towards the Rails style migrations.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: