[velocitypsycho]

For installing using .deb files, how are db migrations handled. Our deployment system handles running django migrations by deploying to a new folder/virtualenv, running the migrations, then switching over symlinks.

I vaguely remember .deb files having install scripts, is that what one would use?

[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.

[stephenr]

Depends on your infra. If it's a single server with the app + Db (or a single app server + single DB server) you could have a postinst script that calls your app/framework's migration system.

If your migration system is smart enough (or you can easily check the migration status from a shell script) you could also do this in a multi-app-server environment too.