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.
Figure 1 – an example of a mixed automated and manual build pipeline
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.
magpiebrain 
4 Responses to “Automating the build pipeline”
Very nice diagram. I appreciate your point about automated v. manual artifacts, and am loathe to give up on full automation. However, the latter tests you present are, by definition, manual as they are the chance for actual human input into using the final artifacts (if I understand your diagram correctly).
Yes, which is the point I was trying to make. A proper, full build pipeline can extend at least as far as producing an artifact that the business are happy to deploy directly – it may even extend to carrying out the deployment itself. Any system used to manage such a pipeline must allow parts of the pipeline to be manual – in effect the pipeline blocks waiting on human input. I’ve used the example of QA sign-off before – the business might require that a QA examine and accept the changes before proceeding, in which case your build pipeline system might have a task which raises an issue in Jira asking for signoff, and blocks until it’s resolved one way or another.
Have you seen the build pipeline plugin for the cool Hudson and Jenkins CI server? We use it to help our clients achieve the goals you touch upon. That is a visible, automated (with optional manual authorisations) and auditable path to production.
It’s free, so have a look – http://www.centrumsystems.com.au/blog/?p=121
And now we’ve released 1.1 of the plugin with some major improvements. Please have a look at the release notes and give it a try:
http://www.centrumsystems.com.au/blog/?p=165