Continuous Integration with Python
Ok – confession time. I missed something really important when it comes to Continuous Integration using Python.
Previously, whichever tool we were using for our Continuous Integration builds, we would create a bundle of scripts to get the code built and tested.
Typically, the steps followed were:
- Pull the latest version of code
- Create a virtual environment
- Install dependencies
- Run unit tests
- Evaluate test coverage
- Publish the tested library somewhere
Typically, this would result in some sort of `run-build.sh` – which sort of defeats the point of running a build server if you’re just going to hand-craft your own scripts!
This issue was that not all ‘Custom commands’ in the various build servers (Jenkins, Bamboo, Team Foundation Server/VSTS etc) can be instructed in the same way. They also don’t handle python virtual environments particularly well!
Until now, that is.
One word: tox
What is tox?
Tox is a generic virtualenv management and test command line tool you can use for:
checking your package installs correctly with different Python versions and interpreters
running your tests in each of the environments, configuring your test tool of choice
acting as a frontend to Continuous Integration servers, greatly reducing boilerplate and merging CI and shell-based testing.
In practical terms, tox is a python package which is configured using a simple tox.ini file, looking something like this:
[tox] envlist = py26,py27 [testenv] deps=pytest # install pytest in the venvs commands=py.test
So, now I can run just one command to build in multiple different versions of Python and environments.
How did we miss this?!
If you are like me, then I strongly recommend you give this a shot. You can thank me later.
We Love Data
Want to know more?
Drop us a line – we’re always happy
to chat – we promise we’ll keep the
geek speak to a minimum (unless
that’s your bag in which case we’ll