I've always had luck just running the migrations before hand -- the only real caveat there is that you need to do a two-step migration process if you're removing fields.
If all your changes are additions, and your app is managed by supervisord, it's fairly trivial to pull the code updates, run the migrations, then bounce your supervisor instance.
Like I said though, if you're deleting, the process is to stage out the deletes into a separate migration so that your codebase is using new or added/replacement columns before you remove tables or you're kind of screwed.
Also bear in mind that this knowledge is somewhat dated as all my recent Django ORM experience is based on Oracle (ugh) which I haven't gotten South to work with.
> I've always had luck just running the migrations before hand -- the only real caveat there is that you need to do a two-step migration process if you're removing fields. If all your changes are additions, and your app is managed by supervisord, it's fairly trivial to pull the code updates, run the migrations, then bounce your supervisor instance.
The problem is that some configurations need workers to restart every X requests to avoid memory leaks, and that makes the deployment process completely non-deterministic if you're pushing new code and expecting workers to still serve the old one. There are troubles with dynamic imports too, which happen on large codebases.
That's a good point that I didn't consider. I'm using Gunicorn and now that you mention it, I dunno how much is or isn't dynamic, but my process is dynamic so it takes seconds to happen and may or may not be throwing errors.
I've never noticed any errors deploying as described, but that doesn't necessarily mean anything in light of this information.
If all your changes are additions, and your app is managed by supervisord, it's fairly trivial to pull the code updates, run the migrations, then bounce your supervisor instance.
Like I said though, if you're deleting, the process is to stage out the deletes into a separate migration so that your codebase is using new or added/replacement columns before you remove tables or you're kind of screwed.
Also bear in mind that this knowledge is somewhat dated as all my recent Django ORM experience is based on Oracle (ugh) which I haven't gotten South to work with.