One of the most important components of the work I do for CloudBees as a Sr. Solutions Engineer is the execution of what we call "POC's". These are Proof of Concept projects with customers, in which the customer tells us what they want to see our tools do in order to decide if they want to buy them. It's a classic satisfaction exercise, in which we determine their expectations, deliver a level of performance that creates a perspective in their mind that those expectations have been met, and in so doing create satisfaction. This, in turn, creates a sale. This work in and of itself is very productive and personally fulfilling if the POC is successful, but it also gives us an opportunity to help the customer define a vision for the future; one that our products can enable. As a certified Business Relationship Manager, I try to bring those skills to the engagement with the customer and help them to construct that vision and help the customer get the most value out of their investment. A recent engagement gave me the opportunity to do just this. A very prominent software company in New England decided to move ahead with a POC for CloudBees Accelerator .
The major pain driving this POC was the length of time it took to build the Linux and Windows versions of their products -- from 6 to 8 hours each, under ideal conditions. The goal of the POC was to demonstrate that this could be reduce by a factor of 6x to 8x. The POC quickly succeeded in demonstrating a reduction in the build time of the Linux version that exceeded their wildest expectations. With a single 16 core box running the same number of Accelerator agents, we reduced the build time from hours to minutes . Less than an hour, in fact. To be quite honest, we barely broke a sweat achieving this, though there were factors that obviously cooperated. Their build was easily parallelized due to the low volume of dependencies, and the agents were sitting in a box that was dedicated to just our builds. When it came time to review the partial result of the POC, the senior management staff were ecstatic. They honestly did not think we would achieve the goals of the POC, let alone blow by them like they were standing still. We showed our results, and then we had a discussion on the need to validate them by running regression testing and comparing binaries. At the end of the meeting, I brought up a different subject for the senior managers to consider. If the builds are going to run so much faster,what opportunities will this open up for the business?
Build acceleration means that Continuous Integration is now possible, no? If it only takes minutes or seconds to perform an incremental build, that means thatimplementation of Agile development practices are now possible. To orchestrate that, what better tool than CloudBees Flow , with its built in ability to trigger builds on detection of source code check-ins to repositories like SVN or ClearCase. And what about that testing we talked about? The key to Agile in Continuous Delivery is not just the ability to deploy quickly and consistently with a tool like our CloudBees Flow -- it also requires the ability to perform tests quickly . If you can define the execution of a build in a Makefile, so can you define tests for parallelization, no? CloudBees Accelerator can do that, as some of our customers have already discovered, much to their surprise and glee. I could almost hear the gears turning in the senior manager's minds. When they began discussing how their teams in India had been asking for the ability to do this, I knew I had accomplished my short-term mission.
Expectations +/- Perspective = Satisfaction.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.