Question About South And Migrating to Production

[Mark Phillips]

I started a django 1.6 project in a virtual environment (Debian, python 2.7) and installed south.I created the models, database, performed many migrations and it all worked well. All with mysql.

I then split the settings.py file into production and development and  set up a production server on apache with wsgi. I successfully moved the app to production using fabric, and can update production from development and it all works.

On the development machine I created two databases - inventory_dev and inventory_prod. I cheated, and just did a mysqldump of the original database and then inserted the dump file into the two databases. I can switch the app on the production machine from dev or prod databases easily.

My question is what happens when I change the database on the development machine. I can use south to migrate the database with no issues. I can deploy the new version of the app to the production machine with no issue. Since I have two settings.py files, can I migrate both the dev and prod databases on the production machine? Something like

./manage.py schemamigration --settings=production inventory --auto

./manage.py migrate --settings=production inventory

And then the same for --settings=development? Or, will south get its knickers in a twist with something like this. 

I could drop the development database on the production machine if necessary. I am using it to see if the deployment works, as it has data in the database. The production database is currently empty, but I need to start filling it up soon. I think of the development database on the production machine as a testing database.

Thanks,

Mark

[Me Sulphur]

We have used South for staging and production for a while now (what good otherwise it is?). Our deployment flow is something on the lines of:
(Note: Tasks are automated using Fabric)

1. Have a production_settings.py file in the git repo
2. Migrations are also commited to the repo
3. When changes need to be deployed, a git pull is executed on the server
4. production_settings.py is renamed to settings.py (simple "mv" command on linux)
5. The fabfile contains a list of apps that need to be migrated (ex: ['app1', 'app2', 'aap2'])
6. Migrations are then executed for the apps in the list on the server (./manage.py migrate <app>)

(Note: branches are used to segregate dev and production migrations)