As described before, the build pipeline is a series of builds, each performing some specific task. The result of one build becomes the input of the next.
Many people see the pipeline describing only those parts which can be automated – as such, you’ll often see the pipeline end far short of production ready code – once it’s got past the final automated barrier, the code then plunges into a grey mass of manual, distributed, often ad-hoc processes. For the build pipeline to work at all, it has to be continued all the way to producing production ready code. That is not to say the whole pipeline should be automated.
The decision on what should/could be automated is secondary to the decision on what your pipeline should be – and the exact nature of the pipeline depends on the nature of the project you are on.
Build automation comes at a cost, and that cost has to be justified in terms of the benefits it brings – I would argue that the less a particular build is run, the less benefit will be gained from automating that part of the build. It might not even be possible to automate some parts of the pipeline – for example, what if you’d decided to make the final barrier of code acceptance a 2 week trial in your call centre?
In figure 1, we have a relatively simplistic pipeline. Our developer and QA builds are run fairly often, so we have automated them. The soak and operational acceptance tests are not, so we kept these as manual processes.
The interesting point here is that we may need some way for the artifact of an automated build to become the input of a manual build, and likewise the output of a manual builds to become the input of an automated build. I’ve seen ad-hoc processes for handling the result of automated builds becoming the input of subsequent automated builds (for example the remote-force build support in CruiseControl, or child builds) but I’ve yet to see a satisfactory solution to bridging the gap between manual and automated builds. Such a solution might want to become part of a higher-level pipeline management tool, responsible for keeping track of where a given check-in is in the process.