[viraptor]

Depends on your environment, number of hosts, etc. really. You probably don't want to stick it into the same install script because:

- your app user doesn't need rights to modify the schema

- you need to handle concurrency of schema upgrades (what if two hosts upgrade at the same time?)

- if your migration fails it may leave you in the weird installation state and not restart the service

Ideal solution: deploy code which can cope with both pre-migration and post-migration schema -> upgrade schema -> deploy code with new features.

[jlees]

For e.g. changing the format of a column that's easy enough but it's tricky to create that intermediate state at the migration level for every migration. One option is to deploy the migration code without restarting the running services (or to a different box), rollback the code if the migration failed, restart the services to pick up the new code if it succeeded. This still means not writing migrations that actively break the running version though - if you're using database reflection, everything will go boom when the schema changes.