Question

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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).

友情链接