The Texas Digital Library has been using the Django framework for a growing number of our smaller projects. Typically, if there’s not already a well established open source solution for the task at hand then the default answer is to write it in Django. Our faculty directory and request systems are already implemented in Django and we are currently refreshing our account management system into the framework. As our use of Django has grown, our practice of storing these projects in the version control repository as one unit has shown its weakness. Within the version control repository, we have passwords, database connections, and file locations stored; in general different settings between production vs development. This makes it hard to keep track of the settings for production vs pre-production and the development instances. This post is my attempt at describe a set of best practices for how to store Django projects in a code repository and deploy them between production and development environments.
Django Applications vs Projects
Django provides tools and concepts to break up your websites into very small components that can be re-used between sites. The first and most basic distinction that needs to be understood is Django’s difference between applications and projects.
A Django Application is a single self-contained set of related features that depends upon the Django framework. By convention, a Django application typically will contain:
views.py, and other files. These applications should contain no configuration that needs to be changed between installations.
A Django Project is a collection of applications that share a single database configuration, work together in a URL space, and share a common set of application configurations. Projects may contain multiple applications or just one. Django requires that projects have at least three files:
urls.py. I believe it is best to consider Django Projects like Apache’s