Cruise: Pipelining for fast visual feedback
One of the cool features in build servers like Cruise and Team City is the ability to create build pipelines.
I have done a bit of work using this feature in previous projects but the key driver for doing so there was to create a chain of producers/consumers (producing and consuming artifacts) eventually resulting in a manual step to put the application into a testing environment.
While this is certainly a good reason to create a build pipeline, a colleague pointed out an equally useful way of using this feature to split the build into separate steps pipelined together.
By doing this we get a nice graphical display from the cruise dashboard which allows us to see where the build is failing, therefore pointing out where we need to direct our focus.
One way to use the pipelines is to work out the distinct potential areas where you would want to signal that something needs to be investigated and then make each of these targets a separate build target.
For example we could set it up like so:
No dependency build =>
Services build =>
End to End smoke test build =>
Full build
Benefits of this approach
The benefit of this approach is that it helps to create more confidence in the build process.
When we have a long running build it is easy to get into a state where it is failing after 3/4 of the build has run and all we get is the red failed build to indicate something has gone wrong. We can drill down to find out where the failure is but it’s not as obvious.
The approach we have taken to checking in is that it is fine to do as long as the first stage of the build is green. This has worked reasonably well so far and failure further down stream has been fixed relatively quickly.
Things to watch for
We have setup the final step of the build to be a manual step due to the fact that it takes quite a long time to run and we’ve been unable to get a dedicated machine to run an agent on. Ideally we would have it running constantly on its own agent.
This isn’t run as frequently as when we had it running automatically and I guess the danger is that we are pushing problems further down stream rather than catching them early. Hopefully this issue will be solved if we can get a dedicated agent running this build.
We’re still looking for ways to improve our build process but this is what’s currently working for reasonably well for us at the moment. It would be interesting to hear what others are doing.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.