There are many ways to set up and configure a local environment for Django development. In this post I provide a high level overview of some tips and techniques that I use.

Django Development / Production Parity

The goal is to create a development environment as similar as possible to your production environment. You usually can't create an exact duplicate, particularly for larger systems, but you can eliminate as many differences as realistically possible. Attempt to make the following as identical as possible between your environments:

• Operating systems
• Python, Django and other Python packages
• Databases
• External dependencies (file storage, message routing, etc)
• Tools used by each developer

Work in a virtual environment

A virtual environment isolates any packages/dependencies to that environment so they do not impact your system level packages or packages in another virtual environment. In the Python world, the standard tool for creating and working with virtual environments is virtualenv. Each Django project you work on should have its own virtual environment, or multiple virtual environments if you need to test or validate the project against different dependency versions.

I also recommend using virtualenvwrapper when working with virtualenv. It just makes the process easier.

Install dependencies using pip

pip is a tool for installing Python packages from the Python Package Index (PyPI). Use it to install all of your Python packages and dependencies for your project - including Django. Freeze your package list to a requirements file.

Database

Always use the same database in each of your environments, including your development setup. Don't try to get away with using SQLite3 on your local machine.

Again, the goal is to keep your development environment as close as possible to your production environment. Sure, Django's ORM abstracts away most of the differences between different databases. But if you are trying to debug a data or database related issue, and sooner or later you will, you don't want to want the headache that comes with having different databases in different environments.

Here are some of the benefits you get by using the same database:

• Use the same tools to analyze and work with data in each of your environments.
• Easily extract data from one environment to load in another environment.
• Same data types in each environment.
• Scripts, migration code, database procedural code (triggers, stored procs) all work the same in each environment.
• Code execution paths in ORM are likely to be much closer, eliminating a lot of hassle when debugging.

Version Control

Use whatever you want, just make sure you use some form of version control. Preferably use an online hosting service (like GitHub or Bitbucket) to host your repo in addition to your local copy.

Multiple Developers

Setting up environments across a team of developers often introduces small differences from one developer to the next. A newer tool that helps to relieve this issue is Vagrant. Vagrant is a tool for building environments in an automated and reproducible manner - build an environment on each machine using the same Vagrantfile and each environment will be identical.

Check out the docs for detailed information on how to install and use Vagrant.

---

What tips do you have for setting up a development environment?