CHAPTER 20
Continuous Integration (CI)
As our site grows, it takes longer and longer to run all of our functional tests. If this
continues, the danger is that we’re going to stop bothering.
Rather than let that happen, we can automate the running of functional tests by setting
up a “Continuous Integration” or CI server. That way, in day-to-day development, we
can just run the FT that we’re working on at that time, and rely on the CI server to run
all the tests automatically, and let us know if we’ve broken anything accidentally. The
unit tests should stay fast enough that we can keep running them every few seconds.
The CI server of choice these days is called Jenkins. It’s a bit Java, a bit crashy, a bit ugly,
but it’s what everyone uses, and it has a great plugin ecosystem, so let’s get it up and
running.
Installing Jenkins
There are several hosted-CI services out there that essentially provide youwith a Jenkins
server, ready to go. I’ve come across Sauce Labs, Travis, Circle-CI, ShiningPanda, and
there are probably lots more. But I’m going to assume we’re installing everything on a
server we control.
It’s not a good idea to install Jenkins on the same server as our stag‐
ing or production servers. Apart from anything else, we may want
Jenkins to be able to reboot the staging server!
We’ll install the latest version from the official Jenkins apt repo, because the Ubuntu
default still has a few annoying bugs with locale/unicode support, and it also doesn’t set
itself up to listen on the public Internet by default:
365