Common errors when moving a django app from dev to prod?

Question

I am developping a django app on Windows, SQLite and the django dev server . I have deployed it to my host server which is running Linux, Apache, FastCgi, MySQL.

Unfortunately, I have an error returned by the server on the prod while everything ok on the dev machine. I've asked my provider for a pre-production solution in order to be able to debug and understand the problem.

Anyway, what are according to you the most likely errors that can happen when moving a django app from dev to prod?

Best

Update: I think that a pre-prod is the best way to address this kind of problem. But I would like to build a check list of what must be done before to put in production. Thanks for the very valuable answers that I received until now :)

Update: FYI, I 've implemented the preprod server and the email notification as suggested by shanyu and I can see that the error comes from the smart_if templatetag that I am using on this new version. Any trick with template tags?

Update: I think I've fixed the pb which was caused I think by the Filezilla FTP sending. I was using the "replace if newer" option which I guess is causing some unexpected results. Using the "replace all" option fix the issue. However, it was an opportunity for me to learn more about deployment. Thansk for your answers.

Answer 1

Problems I typically have include:

1. Misconfigured productions settings, whether in my production localsettings.py, wsgi/cgi, or apache site files in /etc/sites-available
2. Database differences. I use South for migrations and have run into some subtle issues when performing my migration on PostgreSQL when it worked smoothly in sqlite.
3. Static file hosting since I cheat and use the Django server in development
4. Permissions, both on the file system and within the database
5. Rare, but possible, network issues preventing me from getting my dependencies, whether on PyPi or some 3rd party site

Ways that I have mitigated these issues:

• Use the same database in production and development (in your case, MySQL everywhere)
• I've found it is useful to have a "test" environment which mimics production in every way possible (it can be on lower end hardware, or even the same machine). This way, if there are any issues in this "production-like" enivornment, I can solve them without taking my production server offline.
• Script everything for repeatable deployments. I use fabric, but zc.buildout or Paver would also work. These tools help reduce typos while deploying and reduce the time to deploy my app.
• Use version control (mercurial, git, subversion) and a schema migration tool (like South), so if something does go wrong when you deploy to production, you have the possibility of backing out the changes and allowing production to run on the old code with the old database schema.
• I haven't set up an "egg proxy" yet, but I am considering it, to avoid issues when downloading dependencies.
• I've found pip's freezing dependencies to be useful, in case a new, incompatible change to a library occurred since I downloaded it initially
• Use a web testing framework like Windmill or Selenium to test my application in my "test" environment, so that I can get a lot of test coverage of my system very quickly.