One feature in Rational Team Concert that changed my approach to my job in a subtle but unbelievably freeing way is the support for personal builds. A personal build is an automated build that runs against code in a developer’s private repository workspace instead of code in the team’s shared stream. Here is what the Request Build dialog looks like when I request a personal build of my team’s build definition:

The personal build checkbox is available only for build definitions that specify Jazz Source Control in their configurations.

Personal builds seem such a simple thing; how can they make a difference in my life as a software developer and member of a team? To answer that question, let me tell you about my life before Jazz and personal builds. Previously, I worked on a project that had one continuous build for the entire project. When the continuous build began failing, it was crucial to get it back to passing as soon as possible, because a failing build could distract multiple developers and hide failures caused as other team members delivered code.

Dozens and dozens of developers worked on the project. We each made our changes on our personal machines and built in our IDEs. If the product built and our tests passed on our personal machines, we delivered to the central code repository and waited for an automated build. If the build completed and the tests passed, we went home happy. If the tests did not pass, the developers who delivered code had to determine why the tests failed and deliver fixes as soon as possible. This meant working under time pressure every time the build broke.

In the Jazz project, on the other hand, each component has its own continuous build. The exposure when a continuous build fails is much less than it was on my previous project. In fact, different components have different expectations about how often their continuous build will fail. Still, in my early days on the Jazz project, I had an uneasy feeling with each of my deliveries. If I added a plug-in or feature to our codebase, I would nervously monitor the automated build that followed my delivery and sometimes work late into the night trying to figure out why something that ran fine on my development machine failed on the build machine.

This changed when Rational Team Concert began supporting personal builds. Suddenly, I could request a build that would run on the build machine and use exactly the code I had in my repository workspace. This meant that I could build and test my changes with the team’s continuous build without delivering the changes to the rest of the team. If my changes caused a problem with the build, I could fix the problem without undue time pressure since no other developers considered the build to be failing.

Because personal builds are not operating on code shared by the team, Rational Team Concert does not include personal builds when determining the status of a build definition. This means that my personal build could fail without my team’s build status going from green (OK) to red (Error). To other members of my team, the continuous build was still passing. Only the result of my personal build was red. No longer did I need to watch nervously after I had exposed my changes to the team. I could deliver code confident in the knowledge that it had already built and run successfully in our continuous build.

The fact that I could build with my changes without exposing them to the rest of the team was enough to make me a convert to personal builds. But, there is another advantage to personal builds that I soon discovered. Personal builds free up my machine so that my development activities are not slowed down while I run an automated build. Personal builds run on the team’s build machines, not on a developer’s desktop machine. This means that I can simultaneously run a personal build and develop new code without dealing with the load of a resource-intensive process started by the build.

The Jazz team has incorporated personal builds into our development process. During the final iterations of Rational Team Concert 1.0 development, we began using them as a way to ensure stable integration builds and to keep changes in the global integration stream from affecting every developer on the team. Essentially, we used personal builds to perform a “pre-integration” of all the global team changes before accepting them as our local team’s new stable base, upon which we do day to day development.

One developer from each component team accepted all the global team changes into her repository workspace and ran a personal build before exposing the rest of her local team to the changes that had been delivered to the global integration stream. The personal build used the code that was in her repository workspace, which was the latest from all of the teams. When the build completed successfully, the developer delivered all the changes to the local team’s stream so that the rest of her team could see them. She also delivered changes from her team to the global integration stream where other teams picked them up. Since the personal build was successful, there was less chance that a build problem would appear when the real global integration build was run.

Personal builds have continued to play a prime role in our development for Rational Team Concert 1.0.1. We continue to use them within each team when accepting from and delivering to our integration stream. We also use them liberally when delivering certain changes that have a higher likelihood of breaking our integration build. Because this is a maintenance release, stability of the code base is big concern. It is important that our integration builds are successful and that teams do not deliver code that will break others or the build. For this reason, the Jazz team requires that developers delivering certain changes, such as the addition of new Eclipse features, run a personal build of our integration build definition before delivering. This screen capture of the Builds view populated with recent weekly integration builds shows how often we use personal builds:

I recently started writing code for the Jazz Process component. My first delivery included adding new plug-ins and features to our build, as well as beefing up test coverage in some areas. Before I released my changes to my new teammates, I requested several personal continuous builds and a personal integration build to make sure my additions were being included in the builds and were running as they should. You can see one of the personal builds that I requested in the screen capture.

Personal builds have freed me from fussing over builds that run after I’ve released changes and have made the Jazz team’s integration builds more stable. Imagine what they can do for you.

If you want to see the story for this feature, see Story 42838. If you want to read the discussion amongst the Jazz developers that led to this feature, see Plan Item 12423.

(P.S. Yes, the title of this blog is borrowed from the subtitle of Dr. Strangelove.)