Tuesday, June 9, 2015

Deploying a Django application - Part I

Well, first and foremost, this blog just crossed 1000 page views. Sincere thanks to all readers. Despite what the title indicates, this is not the last post. The world of Django is ever changing and there's always new stuff to learn. But this post (or series of posts, haven't decided yet) will show you how to deploy the project you've created to a server and make it battle ready.

I was recently drafted by my college to create and deploy an online mentorship platform. We have a mentorship process that involves scheduling meetings with mentors and discussing attendance, marks and also stuff like grievances. The college wants to make it paper free. So here I am. It's a point of pride, because I'm creating and deploying all by myself.

Anyway, first off, let's see what all we need to pull this off. Here's the list:

  1. Working Django code (duh.)
  2. A dedicated computer that will act as a server. Specifications:
    • At least 4 GB RAM (to handle multiple concurrent requests)
    • At least 500 GB Hard Disk space (to store the database and static files)
    • Django installation: same as or one compatible with the one you developed your project in
    • A static IP address that is unique within the network you want to host the service in
    • Side note: You might want to consider multiple servers if you anticipate thousands of requests per hour. Otherwise just one is OK
Have you got all this? Great! Now let's see what changes you need to make in the code to make it deployment ready. Here are a few things off the top of my head. They're pretty basic. We'll go into more details in subsequent posts. I guess I've made up my mind now :P Anyway, here they are:

  1. Change DEBUG = True to DEBUG = False in the settings file. The reason for this is that if there's an error Django gives you the comprehensive report, along with some part of the code. You don't want the users to be able to see that
  2. If you need to have that, you can make two settings files: one for development and one for production. Here's how:
    • You can have two copies of the same file, with DEBUG True in one (development) and False in the other (production)
    • Alternatively, you can have a settings_production file that will import the main settings file. That way, all the user will see is an import statement in case of an error
    • Note that all this configuration and switching between two settings files have to be registered in the manage.py file before running the application
This is the initial preparation you need to make. I'm discontinuing here so that the post will be of appropriate size and not tedious to read. Keep checking!