I looked at the existing codebase and taking into account my experiences with previous Django projects/deployments I would suggest to do the following:
- Change directory structure to something more modular and structured
- Lose all old south migrations and create inital ones for 1.8
- Check all models for changes with 1.8, because there will be
- Get a mysql slave up on my vps to test the new setup
- Use nginx as reverse proxy for gunicorn and to serve static content (and node.js if it's used)
- Use supervisord to keep an eye on processes (gunicorn, node.js, etc.)
- Integrate existing config in a more generic way of handling configs (dev/staging/live)
- Start rewriting views (from what I have seen, this should be quite doable with existing packages like django-class-based-auth-views and the work already done)
- All jinja2 => django templates (yawn, this is going to be the boring part)
- All ajax and client side JS that needs refactoring
- Make it deployable via Travis-CI
Like I said, would be cool to be able to do this, but the changes are quite radical, so I forked the repo and will start working on that.
Cheers, Richard
Well, gunicorn is just what I've seen people use and I'm quite happy with it, but I'm not saying we have to use it ;)
Okay, I'll dive into that. I do have some experience with django-allauth which also includes openID
http://django-allauth.readthedocs.org/en/latest/providers.html