Test-Driven Development with Python, 3rd Edition

Chapter 25. CI: Continuous Integration

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 “continuous integration”, or CI. That way, in day-to-day development, we can just run the FT that we’re working on at that time, and rely on CI to run all the other tests automatically and let us know if we’ve broken anything accidentally.

The unit tests should stay fast enough that we can keep running the full suite locally, every few seconds.

Note

Continuous integration is another practice that was popularised by Kent Beck’s extreme programming (XP) movement in the 1990s.

As we’ll see, one of the great frustrations of configuring CI is that the feedback loop is so much slower than working locally. As we go along, we’ll look for ways to optimise for that where we can.

While debugging, we’ll also touch on the theme of reproducibility. It’s the idea that we want to be able to reproduce behaviours of our CI environment locally—in the same way that we try and make our production and dev environments as similar as possible.

CI in Modern Development Workflows

We use CI for a number of reasons:

• As mentioned, it can patiently run the full suite of tests, even if they’ve grown too large to run locally.

• It can act as a “gate” in your deployment/release process, to ensure that you never deploy code that ...