Setting Django Dev & Prod Environment
Here is the quick post on how I setup my django development and production server. I know everybody has their own type of server setup but I just wanted to share mine. So basically I created two apache instances which run production and development servers respectively. If you are with webfaction this would be a piece of cake. However if you are on a slice/ dedicated server setup, you can use another webserver(a little complicated approach) or just use django development server to run on a custom port.
Production: www.domain.com Development: subdomain.domain.com (Ex: sandbox.domain.com)
Ex: _Production:_Nginx running on 80 serving media and proxying django requests to Apache/wsgi instance running on a custom port. Development: You can fire the django development server on a custom port and for media use the same nginix instance.If you are with webfaction you can create 2 seperate django applications and use a Static app to serve the media.
Make use of your Version Control which makes your life easy. In the past I had a very ugly approach of using FTP to connect to the server and then make changes in the code on the fly. This would create a bunch of 500’s to the visitors. I realized that there should be a better solution, until I realized this approach. If you are using Subversion you can checkout a copy of the code to the development setup and work on it and then commit the changes back to the repository. After you make sure everything is working, you can simply checkout the code from the repository into the production server and simply restart the server. The same approach would work with GIT, Bazaar as well but with a subtle difference. You can simply add the development repository as a remote and pull updates into the production setup.
Other Advantages would be like: 1. Avoid caching in development setup You can ignore the settings.py file in development setup, so that production settings can be different. In development setup you can disable caching so that you can observe changes immediately.
2. Use a different database for development You can use the same database of the production or setup a different database just for the development purpose. You can create a local_settings.py file where you can put all your development server credentials and include this piece of code at the end of settings.py file so that it overwrites values in settings.py
try: from local_settings import * except ImportError: pass
In this way it tries to import local_settings.py if its not found an error wont be raised. Make sure your version control doesn’t track local_settings.py.
3. Make use of Django-debug-toolbar Rob Hudson created a django-debug-toolbar after djangocon which is amazing. You can see all the queries which ran to generate a page and HTTP headers which contain session variables, any form data etc. Its an amazing way to debug a django app. You can install django-debug-toolbar in your local_settings.py and set ignore app on django-debug-toolbar so that your version control doesn’t track it.
4. Set DEBUG=TRUE: Of course this is a very common setting to have debug true when you are developing so that you can get a trace back of the error. However if your development server is public you can set DEBUG=False and check your ADMINS emails for the trace back.
On the whole make your development environment same as production environment, so that testing and debugging the project will be easy.
Is there any better way than this so that I can use only one apache instance to serve both dev and production versions?