The ISTQB defines continuous integration as such:

“Continuous Integration (CI) is a practice in Software Engineering, where all the developers’ local working code bases will be merged to share with a common repository several times during the product development. It was first adopted as a part of Extreme Programming (XP).”

So to make more sense of this, I’ll describe two different ways of working.

Firstly, the old way:

Developers work on a product.  Lots of code changes, lots of merges.  Although the developers may test their builds locally (and it works), once 50 layers of other changes are loaded on top of it in the main software repository, eventually things don’t work as expected.

When the next release of the product is due, the chance of errors occurring in the build of the untested main code is high, and the chance of the product working is low.

Now imagine that out of the 50 code changes, change #3 was wrong.  The next 47 sets of changes are build atop this, all going slightly wrong in subtle ways.

To fix this?  First, track the fault back to the source, then fix it.  Then fix any other layers of code affected by this.  This is slow, expensive, and error prone.  It also means multiple rounds of testing to finally iron out all of the bugs.

And now, the Continuous Integration (CI) way:

A developer checks his changes into the source code repository.

The CI server detects this change.  Then, it…

1. Checks out its own local copy,
2. Builds it (using an automated, consistent build script *),
3. Deploys the code to a test server, and
4. Runs the unit tests against the product automatically.

The CI server immediately gives a readout about the functionality – has this change broken anything?  If so, how big is the impact?

If any problems are encountered here, a fix can be done – either to the product, or to the unit tests (which may legitimately need refactoring to match the adapted / changed functionality).

Either way… the product is fixed in a very short timescale, and fixed cheaply.  Subsequent changes by other developers also go through this process, and none of the flaws in the code are retained.

The other benefit of this is that the QA team can (at any point) have a build for testing with, allowing for fast turnaround of confirmation testing of the issues.  Again, faster, and easier. 

So to summarise the benefits of continuous integration?

Build early, test fast, stay cheap!

Here’s what Wikipedia has to say about Continuous Integration:

• https://en.wikipedia.org/wiki/Continuous_integration

I have used Bamboo as a Continuous Integration system, and have found it to be useful and productive.

• https://www.atlassian.com/software/bamboo

* This may seem like an odd thing to say, but when a product is complex, manual build processes are slow and error-prone, and can be a source of product failure all of their own.