views:

190

answers:

4

Hi, I've getting quite fast with a small django project of mine, which I'm developing locally, of course. But, as I had never worked with django before, I'm not aware of what it implies to upload it and test it on a production server. And I'm quite curious, since I'm very eager to test an early release live.

I know there is this document, which I think it'll be really helpful: http://djangobook.com/en/2.0/chapter12/

But, are there any details I should take into account before, during and after the deployment? Any advice or best practices?

Thanks.

+5  A: 

Make your development/testing environment match your deployment environment as closely as possible. This means using e.g. PostgreSQL and mod_wsgi instead of SQLite and the built-in server. This software is free so there's no reason you can't get your hands on it.

Ignacio Vazquez-Abrams
That advice applies to any and every dev./acceptation environment in any and all languages :)
extraneon
Thanks, that's definitely a good advice. *I am* running on the built-in server and sqlite :D
ign
+1 - I use the built in server + sqlite for quick prototyping, but I would recommend a matched set of Dev + Staging/Test + Production environments using the "real" software setup for anything else.
Frozenskys
See this question for a way to auto reload on code changes when developing on mod_wsgi: http://stackoverflow.com/questions/1093732/apache-django-mod-wsgi-auto-reload
Luper Rouch
+1  A: 

I think a lot hangs on the change of the database model. Django can add new columns with syncdb, or generate a script to do that, but it will not remove columns and I don't think it will remove foreign key constraints from the database even if they do not apply anymore.

So database migration might be best done scripted, and tested on a copy of the production database or some data set closely resembling production data (the same schema of course).

extraneon
How do you add new columns with syncdb ? is it a new feature ?
Luper Rouch
python manage.py syncdb
extraneon
+2  A: 

You might run into problems if you serve your site on a subdirectory of a domain: avoid writing absolute urls by hand, use the url tag instead.

If you rely on initial data in the database, use fixtures.

If your server will be used for multiple sites, consider packaging your site with Virtualenv to avoid dependencies conflicts with the other sites.

You should also use the same database system in your dev and production servers to avoid surprises.

Luper Rouch
Thanks, great advice too. I'm using url tags. Fixtures... couldn't make it work yet.
ign
+1  A: 

Use something like south to remove database migration pains, and consider something like buildout or fabric for deployment if you have a reasonably complex project (or have the time to learn these tools), as they will allow easily reproducible scripted deployments.

Frozenskys