Two scoops of Django is a good book, and I recommend it to anyone who's working with Django. So when I finally got around to using travis-ci I turned to the packaging and testing chapters, but couldn't find anything that would really help me. Travis is a continuous integration service and is free for open source projects. Travis itself is also open source, so you can run your own servers in-house if necessary.

Why would you want to use it? It allows you to test your applications against different OS configurations, so you can make sure your code will work on other setups, and not only on your own developement box. Even if you already test on two or three different systems, Travis will probably be an improvement. Travis-ci supports many languages other than Python, a variety of databases and even xvfb for GUI tools, which is handy for in-browser testing.

Self-contained tests I always thought a package should have self-contained tests, so that you can run them without adding the app to a local project. The book focuses on doing project-wide testing. I used to use an approach of including a minimal test project in the package's source tree but have switched to a different method and run the tests from a single Python script. Ben Welsh has written an interesting post that contains a code example. I still use a project directory when additional files are needed, think templates, javascript files, etc.

Getting started with Travis Because of this approach it was easy for me to get started with Travis. If your application has the ability to run it's tests in a similar fashion and is hosted on github simply go to the travis-c website and follow the getting started documentation. After that you'll have to create a configuration file, .travis.yml . A simple example could look like this: language : python python : - 2.5 - 2.6 - 2.7 env : - DJANGO_VERSION=Django==1.3.5 - DJANGO_VERSION=Django==1.4.3 install : - pip install --use-mirrors $DJANGO_VERSION - python setup.py install script : make test This example uses make test to run the tests, but if you have a different method like python setup test you can simply change the script configuration. It can be anything that returns zero for success and something else for failure. With such a minimal setup you'll have your app tested against Python 2.5, 2.6, 2.7 and Django 1.3 and 1.4. I have a simple Django app on github that you can look at for a slightly more complex configuration that tests against more Python and Django releases while excluding combinations known to fail .