The Build AssemblyLifePipeLoom
•
Dave Farley, co-author of Continuous Delivery
(I got my copy last month - more on that in another post) commented on a blog post about the origins of the term build pipeline. He might well do, as it was his idea to make the pipeline concept central to the book.
Being a bit of a geek I called it a pipeline not because it is like a real pipeline, transporting a fluid, but because it reminded me of instruction pipelining in CPUs. Effectively the deployment pipeline (aka build pipeline) works, as a process, by doing branch prediction. We assume that later stages will pass, and so can move on to work on new stuff as soon as the commit stage has succeeded. If subsequent, post-commit, pipeline stages pass, we have won our gamble and so have made progress faster, if they break we have a pipeline stall and have to go back and fix the failure.
UrbanCode came up with the idea of Build Lifecycle.
Jason Yip once suggested that the model for Continous Integration has always been the Toyoda Loom.
I prefer the term Build Assembly Line. Think of engines plopping out from one part of the factory, being inspected and sometimes kicked off the line. Eventually, you might use an engine, or install it in another assembly and use that.
Doesn't matter which you choose though: What's important is having a metaphor for the thing you're building. Otherwise you'll build something weird.