How We Work: Continuous Integration

We are big believers in continual improvement and efficiency gaining at Eldarion. One way we achieve this is by integrating our code continually and upon doing so running test suite and lint checking.

By automating test runs and linting, more tests get written, code style doesn't slip, and we stay on top of regressions. In order to help you get started quickly in putting your Django project under continuous integration we are providing the skeleton configuration that we use.

For automation, we are big fans of Travis CI. We use them for open source as well as their paid version for private code like that of our own sites. We also start off each client project these days on automated linting and testing on Travis CI.

One of the first things we do when starting a new project is getting it setup on Travis CI to auto-lint the project.

Nothing simpler than just running code checks against your project on every push and this provides the framework to simply add testing once we start adding code, in fact we even go ahead and have it execute manage.py test even though there are no tests to run yet.

A sample .travis.yml file that we use in a lot of projects::

#!yaml
language: python
python:
  - "2.7"
cache:
  directories:
    - $HOME/.pip-cache/
    - /home/travis/virtualenv/python2.7
install:
  - pip install flake8 --download-cache $HOME/.pip-cache
  - pip install -r requirements.txt --download-cache $HOME/.pip-cache
before_script:
  - flake8 .
  - psql -c 'create database PROJECT_PACKAGE;’ -U postgres
script:
  - ./manage.py test
notifications:
  slack: ROOM:KEY

The cache directive, we have found pretty useful in speeding up builds for the same branch, typically our integration branch that we call develop as well as our release branch that we call master.

We use flake8 for linting and have found it the best mix of good coverage, speed, and good signal to noise ratio.

You need to make sure your database is created before trying to run manage.py test so make sure PROJECT_PACKAGE is replaced with whatever you have configured in your settings.py.

A side benefit that we have enjoyed is how pull requests end up getting linted and tested and flagged if anything is failing so issues can be resolved before merge. The value of this obviously increases with the number of active developers that you have on a single project.

Finally, we have a channel for each project we work on in Slack so we setup integrations so that Travis CI can post build notifications there so everyone is always up to date with the results.