This question already has an answer here:

My current automated workflow looks like this:

  • I commit changes
  • I push changes
  • Build (actually just a lot of tests using mock database) is triggered
  • If all tests pass, the new code is deployed to the server

Now assuming there is a change in database format - first 3 steps do pass, but the code will not work on server because existing data is not compatible with new source.

The solution that I'd call nice is to also provide/test the migration code. Which looks like a lot of overhead for something that is executed only once.

The solution that I'd call sane is to stop automatic deployment for such changes, perform the migration, then restart the deployment chain.

Today I was lucky enough that my server is not really widely used yet (I could simply drop everything and live with it) and no changes were required at all. I wouldn't be so lucky in future though. How should I actually handle the database changes?

marked as duplicate by JeffO, Doc Brown, Bart van Ingen Schenau, user40980, GlenH7 Mar 19 '14 at 21:27

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.