In my first post, I described how we were able to increase parallelism and significantly improve the end-to-end build time of the Collaborative Lifecycle Management (CLM) pipeline.  This has provided value in many ways, but as Pete Steinfeld pointed out in his Accelerating CLM builds post, it doesn’t do much to improve the developer experience.  Below I’ll outline an approach to speed up builds for developers that is already being used by some builds and will soon be adopted by more.

Years ago I was involved with one of the first teams to adopt Rational Team Concert (RTC) for internal development.  Developers would make changes to the code and perform some testing on their workstation, deliver the code, and then cross their fingers and hope that it didn’t break the build.  I was not alone in making deliveries that caused the build to fail.  The build functionality provided by RTC was rather primitive at the time (for example the Jazz Build Engine was not able to fetch a workspace), and I spent a lot of energy integrating the build with RTC using the Jazz Build Toolkit and direct API.  Fortunately, the RTC Build team sat one row over from me and provided a lot of help and guidance.  With a little effort, we implemented something I called “private builds” (I’ve never been good at naming things) which allowed developers to run a non-production build in the production environment.  Soon this idea morphed into the “personal builds” that we know and love where developers can run a build based on personal workspace contents and confirm that changes will not break the build.

When people think “build,” they typically think of compiling code, but we’ve added a lot more.  If a product is released only once a year, there can be various manual steps between code compilation and shipping.  But in the world of continuous delivery, we should theoretically be able to ship a new release every day.  We have automated many previously manual steps and integrated them into the build process.  The timeline below shows a build of several components (the components have been renamed, but the timeline was generated from an actual build).

Along with building and packaging the code, there is a lot of other stuff going on including:

• JUnits (tests)
• Static analysis
• JavaDoc generation
• NL Gathering (identifying and validating files for translation)

We want to perform all these things in order to ship, and having them in all our production builds provides value in our continuous delivery structure.  But for personal builds, a developer does not need all the whistles and bells provided by a full build.  Developers want to quickly verify changes will not break the build, so we made changes to allow developers to run faster builds simply by setting a single property when requesting the build.

When the “fastBuild” property (again, I’m not good with naming things) is set to “true”, the build automatically disables things developers don’t want such as NL gathering, JavaDoc generation, static analysis, and various other pieces not shown in the timeline.  The build focuses on the things developers need to verify changes: compiling, packaging, and testing.  Below is a timeline for a build with the “fastBuild” property set to true.

Compiling code is pretty fast.  Tests often take longer (in some of our builds, automated testing takes the lion’s share of the time), but many of the “extra” bits of functionality add up and increase the build time.  In the above timelines, the full build took three times as long as the fast build.  We have found in some of our builds that using the “fastBuild” property reduces the overall build time by 50-66%.

Sometimes I still prefer to run a full build to get the extra functionality (for example the static analysis reports can be useful), but usually I prefer a faster build so I can be more productive.  From my anecdotal experience, I’ve noticed that in builds where the “fastBuild” property is supported that developers use it in 80-90% of personal builds.  I’m eager to see if the performance and usage trends hold as we roll out this functionality for other builds.  I also expect various refinements and changes to improve the process.  One obvious such improvement would be adding a check box to the request dialog so the property didn’t require being set manually.  And of course, it needs a better name . . .

Nathan Bak
Software Engineer, Master Inventor
IBM Rational