Update 1: Fixed arrows on two of the images – damn Visio…

Update 2: Tweaked the final diagram to show build artifacts being checked in and retrieved

Lets look at a fairly simple build.

dev_build.gif

This build is aimed squarely at a developer – at the point the code tags, the developer is happy to continue with his work. The build has satisfied the developer that the code is good enough for what they need to do next. The QA person however, before they start looking to sign off new functionality or bug fixes, might need a little more persuading that the code is in a good enough state for them to look at it.

qa_build.gif

At each point we tag, we have created an artifact – the target audience of which is the developer in the first instance, and the QA in the second. Ideally, this process would be completely automated using a continuous integration approach – the developer checks in, artifact one gets created, then artifact 2 gets created.

Typically one single continuous integration build is used. The problem is that these builds are normally black or white – the whole thing either passes or fails. That means that even if the code is good enough to be tagged for a developers purpose, but not good enough for a QA person, the build fails as a whole. The tests for a QA are also typically much longer running. In order to provide rapid feedback, two builds can be used – one aimed at producing developer artifacts, another producing QA artifacts.

ci_build.gif

So, the QA build only starts when the dev build has passed and produced it’s artifacts. It’s also important to note that the two builds are separate – if a dev build takes one third of the time of a QA build, it would be possible that three dev builds could be performed while a QA build is being run – the next QA build would get the latest dev build artifact. The act of creating a set of artifacts and passing them on to another build with different requirements is called build pipelining.