Tips/Process for web-development using Django in a small team [closed]

Question

We're developing a web app uing Django and we're a small team of 3-4 programmers — some doing the UI stuff and some doing the Backend stuff. I'd love some tips and suggestions from the people here. This is out current setup:

1. We're using Git as as our SCM tool and following this branching model.
2. We're following the PEP8 for your style guide.
3. Agile is our software development methodology and we're using Jira for that.
4. We're using the Confluence plugin for Jira for documentation and I'm going to be writing a script that also dumps the PyDocs into Confluence.
5. We're using virtualenv for sandboxing
6. We're using zc.buildout for building

This is whatever I can think of off the top of my head. Any other suggestions/tips would be welcome. I feel that we have a pretty good set up but I'm also confident that we could do more.

Answer 1

I could basically write a small book about optimizing your Django/Python workflow, both personally and in a team environment. I'll try to just list-off a bunch of brief points:

• 1-5 is fine, that's exactly the point you should be starting from
• The community as a whole has completely shied away from buildout to using pip and pip's associated requirements file
• As a complement to pip, keep a bootstrap.sh script in your project that calls setup.py, this neatly packages your entire project up and makes installation on a new server hilariously simple
• Look into using something like Jenkins for Continuous Integration/Testing/Deployment
• To tie that in to the excellent branching model you linked to, you can essentially have a post-commit hook check for changes to your master branch, and notify Jenkins that it's time to build! (Alternatively, just have Jenkins poll your central git repo every minute, etc).
• On a successful Jenkins build (all tests passed, whatever other criteria you want) auto-deploy to your staging servers (I hope you have staging servers).
• Use Fabric for the deployment process (to staging and production alike). Fabric is a somewhat high-level wrapper around ssh/ftp/etc commands, all in Python, and makes updating servers a breeze. All I do is type fab prod deploy and every single production machine I own is completely updated automatically to the latest version of my site.
• Monitoring of your servers can be done using a healthy combination of Nagios, Graphite, Sentry (a Django app), and Overseer (another Django app)

That should be a good place to start. If you want further advice, I highly suggest looking up any presentation given by the devs over at Disqus (the single largest Django app in the world). They probably know more about optimizing workflows and scaling than anyone else I've come across.

Answer 2

This presentation shows a good collection of tools/practices for python / django team:

• Automated tests (Django built-in)
• Continuous integration (Jenkins, django-jenkins)
• Measure all the things (sentry, statsd + graphite, new relic)
• Scripted database (South)
• Scripted deployment (fabric)
• Configuration management (puppet/chef)
• Virtualised development (Vagrant)
• Test separation (test decorator, customise test runner)

To this I would add:

• Use pip for your dependencies.
• Have a gatekeeper for your main branch so no code can be merge if it doesn't passes all the tests.
• You want to run your tests as often as possible while developing. So make them as fast as possible (i.e. use sqlite for tests) or at least split them between slow/fast.

Answer 3

Actually, I am not convinced that the branching model is that good for working with Git. I was once excited by the branching model as it resembled the one that we used earlier (CVSNT). However, it goes (a kind of) against the Git ideas. It makes things more complicated than neccessary. The commit point is more important in Git than the branch is. It is more apparent if you think about a branch as about the pointer to the last commit point in the branch.

But it may not be your opinion. Anyway, you can introduce or leave the branching model any time, so you can start with whatever model you choose and you will hardly loose anything.

It may be a good idea to read the Pro Git book by Scott Chacon, Chapter 3. Git Branching.