Using git with applications

Another point of interest: You can "template-ify" your settings file. So, for example, if you have this running locally (with a different settings file), just make something like "settings_template.py" which is added to your git repository, and then add "settings.py" into your .gitignore file (and don't add "settings.py" to the repository).

Now, you can instantly share the same django project between your local and remote systems without worrying about blowing away each side's respective settings files, and at the same time still be able to use the automatic update-on-push post-receive hook.

I know I am way late on this, but this topic interests me. However, I am a little confused by what you mean when you say "template-ify". What exactly would be using the settings_template.py?

Nothing would be using settings_template.py directly. However, let's pretend you and I are both collaborating on a Django project, which we want hosted on WebFaction but we also have our own private stacks on our respective local machines for development. We also have our own private PostgreSQL instances running.

The settings.py file is in charge of determining the configuration for that stack and database, and the necessary settings.py file for you, me, and for the WebFaction deployment will all be different.

Now, imagine that we just add settings.py to the git repository. If I set my own database "my_staging_database" with associated password under the DATABASES section in settings.py, and then push my changes to the repository, immediately I break both your deployment and the Webfaction deployment. The remote settings.py changes, and now the remote Django application attempts to use my local credentials to connect to the WebFaction PostgreSQL server, referencing a database that does not exist. The site goes down.

So, instead, we add settings_template.py to the repository to have a good starting point, and then copy that file to a local settings.py on each machine. We then set up the configuration for each machine and tell git to ignore the settings.py file. This way, we can push and pull without ruining each others' (and the webserver's) deploy settings. Hope that clarifies!

UPDATE

I now have changed my workflow a bit and find that the following works a bit better. I leave 'settings.py' as a versioned file, and create another called 'settings_local.py', which is inside of .gitignore. Then, the template is 'settings_local_template.py'. At the end of 'settings.py', add something like:

1
2
3
4

try:
    from settings_local import *
except ImportError:
    pass

Then, define the deployment-specific options in 'settings_local.py', such as DATABASES, STATIC_URL, STATIC_ROOT, TEMPLATE_DIRS, STATICFILES_DIRS, etc.

This allows actual configuration options (like INSTALLED_APPS and MIDDLEWARE_CLASSES) to remain versioned.

Why do you add GIT_WORK_TREE=/home/username/webapps/django/myproject git reset --hard? It's not mentioned in the page you linked to.

I have added this so that if you delete a file in the origin git repository, it is likewise deleted in the application directory on the webfaction server. I remember that originally I had encountered an issue where under certain circumstances extra files would be left around, and performing the git reset --hard more strongly ensures that the server-side application stays in sync with the local development application. This also helps to ensure that you could also add an apache restart command to the post-receive hook without having strange inconsistencies.

Just add commands to the post-commit script to copy the static files to wherever they need to be, eg:

1
2
3
4
5

#!/bin/sh
GIT_WORK_TREE=/home/username/webapps/django/myproject git checkout -f
GIT_WORK_TREE=/home/username/webapps/django/myproject git reset --hard
rm -rf /home/username/webapps/my_static_app/*
cp -r /home/username/webapps/django/myproject/static/* /home/username/webapps/my_static_app/

Or, replace your static-only app with a static-only symlink app pointing to /home/username/webapps/django/myproject/static/ (ie, make your symlink app point to the real directory within your project directory, instead of having the symlink itself in the project directory pointing to a directory outside of it.).

Thank you seanf, I've tried the second solution and that works great. I didn't know that it was possible to serve 2 different folders in 1 app with 2 different http servers (apache/mod_wsgi for the django files, nginx for the static files).