Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This may be a noob question but a colleague and I are working on a project. Some background about our situation is:

  • We control versions using a centralized git server inside our office.
  • We code in PHP, so we try our code offline in a local apache instance.
  • We use local MySQL instances at work.

Our client is a bit of a demanding person, and has changed the requirements more than twice. The main problem is that if we need to change something in the database, we have to make clean dumps on other servers (the other teammate's computer, the central server..., and the client's server of course) to make other instances work, too.

My question is, is there a way to synchronize our local databases (I don't care about the client's one at this moment) with git or another utility to make my colleague, the git server and my database be up to date when we push changes? If that is not possible, do you know of any better way to work with MySQL databases stored locally? Thanks in advance.

PS: Using only one central database is not a valid solution for us, as we test different features and have different elements stored there.

share|improve this question
    
Search for 'migrations php' and you will get a lot of toolkits implementing the automation regarding databases in development. –  idstam Jun 18 '11 at 7:02

2 Answers 2

up vote 4 down vote accepted

First thing you should always do on any project is automate the build, deployment and release processes.

This means in your case:

  1. Automate setting up the database from a clean slate with fresh DDL.
  2. Automate loading any default data into this fresh state DDL.
  3. Automate dumping any data out so that it can be reimported in a single step.
  4. Automate upgrading an existing schema with new DDL.
  5. Automate migration of data from the old schema to the new one if needed.

Make all this available as goals from your automated build scripts, so that you can in a single command line build, the code, configure the database.

Make installation of your code automated as well, RPM or Debian packages are a must here for Linux. Leverage the above scripts for update scenarios from within your package managers.

These can be done with anything ranging from bash scripts, to something like Maven with its plugins, either way it should not rely on platform specific GUI tools if at all possible. This is an extremely common problem domain, and there are great solutions in just about every possible language that you should be able to leverage specific to your environment.

If you don't see it, the recurring theme is automation. Only one person on your team should have to do he above tasks once, and everyone else can benefit from their work. Automation is a force multiplier. The smaller the team, the greater the ratio of the multiplier time wise.

share|improve this answer

There was a question on this in the other place, in answer to which i wrote a long screed. You might enjoy reading that thread.

Briefly, my answer is that you need (a) a process for clearing out and quickly rebuilding a database from scratch, (b) a set of data files to feed into this process, which you keep under source control, and (c) a working process which involves rebuilding your database whenever you bring in changes to those files.

This is what my company does, and as long as you can keep the rebuild process quick, it works very well.

share|improve this answer
    
Thanks for your answer. However, I had to choose one so, as you already answered (and were chosen) in that other question, I chose Jarrod's answer –  Korcholis Jun 18 '11 at 16:13
    
His is also a better answer! –  Tom Anderson Jun 18 '11 at 22:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.