4

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?