Benefits To Storing Django With App Code In Version Control

Question

I'm trying to simply the deployment of our application and more easily manage the versions of libraries and frameworks that we depend on.

Does storing Django in our VCS make sense? This would ideally make it easier for me to streamline deployment and I can manage any model changes that Django makes to the built-in apps (django.contrib.auth, django.contrib.sites, etc.) using South.

Are there reasons why I shouldn't do this? What do you do for your apps?

Answer 1

I would absolutely store everything in your VCS. Want to update Django? Want to add a plugin? Synchronising this across a few developers and different environments could be a nightmare. Nevermind having to debug this if the versions go out of sync. What happens if you have multiple django apps that you need to work on and they're different versions?

You might want to take a look at the following two articles:

• A primer on virtualenv
• Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip

I store everything from the directory that virtualenv creates in SVN. My deployment script basically consists of the following:

• Checkout (only initially, and then update) project to folder on server
• rsync to directory that Apache serves files out of (excluding .svn folders)
• Set database passwords and permissions for that environment
• Restart passenger
• Write out revision number to text file from working copy to deployment directory (could come in handy later!)

Answer 2

I don't think you'll gain much by storing Django itself in version control unless you are using a modified version of Django. It sounds like you're working with other developers, so definitely store code you're working on in some VCS (even working alone there are plenty of benefits).

For deploying your application you may find it's worth building a distutils package which can specify its dependencies (such as a specific version of Django). Using virtualenv will help keep track of dependencies.

I would suggest that for releasing to a production server you should "tag" each release and then export that to your production system, rather than checking it out. This helps to stop people updating things within the tag and updating from version control.

Another thing that I think is worthwhile doing when releasing to a production system is creating a new directory for each export of the code which includes the release number, then have a symlink pointing to the active version. This allows you to roll back to a previous version easily. South, which you mention is also very helpful for this.