Question

I’ve been into django for some time now and most my focus has been around learning how to develop and run applications locally on my development machine. Now I am trying to learn best practices for deployment and release management.

I am trying now to setup my code in github and then somehow setup a production and staging environment where I can push the changes with minimum impact.

Are there best practices out there I could follow? and how do you create an agile environment whereby you can commit your code into a staging environment where customers can view the work as you do it.

Answer 1

setup a production and staging environment where I can push the changes with minimum impact.

This is easy in some cases and hard in some cases.

When you change the database design in Django, you must redo syncdb, and you may have to extract and reload existing data when you do this. This is hard. Some folks use south. We did it by hand because south handles most of the cases, not all of them.

When you release new code (no database change) the upgrades are quite trivial.

1. When Apache starts, mod_wsgi starts.
2. When mod_wsgi starts, it reads the .wsgi files to determine what to do.
3. The .wsgi file — essentially — defines the Django request-reply handling loop that will invoke your application.
4. When a .wsgi file’s timestamp changes, mod_wsgi rereads the file. This will, in effect, restart your application.

how do you create an agile environment whereby you can commit your code into a staging environment where customers can view the work as you do it.

This is pretty easy.

1. Put your application code into /opt/myapp/myapp-x.y/ directory structures. The myapp-x.y name matches a git tag name.

2. Staging is simply a Django configuration using the next release of the app. /opt/myapp/myapp-2.3/. Production is the current release. /opt/myapp/myapp-2.2/. Yes, there are older releases.

3. Define your Apache configuration to have two (or more) “locations”, using the Apache <Location> directive. One location is “production” with ordinary paths. The other is “staging” with other paths. Or use virtual host. Or any other Apache thing that makes you happy.

Now you have both versions running in parallel “locations”.

You can tweak staging by (perhaps) redoing the database, and changing the .wsgi file to point at a new release of your application.

You can tweak production by (perhaps) redoing the database, and changing the .wsgi file to point at the new release of your application.

When you have something releasable, tag it. Fix your Python setup.py and setup.cfg to deploy to the next /opt/myapp/myapp-tag directory.