Rational Team Concert ships with a component we call Jazz Team Build. Jazz Team Build provides several build-related features for the day-to-day user and the release engineer. In addition, Jazz Team Build was designed to be used with your existing build infrastructure such as Rational Build Forge, CruiseControl, and the like. In this post, I’d like to share some of the motivations behind the design of Jazz Team Build. I’ll summarize the key features we wanted to bring to the day-to-day user, and I’ll highlight the design points that actually enable a release engineer (buildmeister) to set things up to make these features a reality for the team. Having a deeper understanding of why things were done a certain way can help you use Jazz Team Build in the most appropriate way possible, given your team’s circumstances.

If you’re completely new to Jazz Team Build, you may wish to read the getting started or tutorial documents, before reading about design rationale.

“Team First”

One of the themes of the Jazz Platform is something we call “Team First” – that is, Jazz-based tools should cater to the needs of teams engaged in the collaborative development of software. In a software development project, builds are a focal point of collaboration. We’re always discussing them with each other. As a developer, you constantly need to know if your latest changes integrated cleanly with the team, or if you’ve broken the build. To debug a customer problem, you’d like to re-create a development workspace from the same code that was used in the 1.0 build. Testers want to know what build a bug has been fixed in. For many teams, builds are the heartbeat of the project, a focal point of collaboration.

Just in case it isn’t clear by now, when we talk about builds, we’re talking about automated builds that run on dedicated build machines.

Because of the importance of regular and successful builds, we wanted to bring builds to the fingertips of the team, to make everyone aware of the different builds the team has, and to show their status and trends.

Our key goals for Jazz Team Build are:

• Make build a first-class citizen in the development lifecycle.
• Bring awareness and control of builds directly to developers, testers, and others.
• Enable traceability between builds, work items, and code.

You can see these goals alive in Team Concert today:

“Viewing recent build status trends”

“Monitor builds I’m interested in”

“Getting notified when a build finishes”

“Navigating from a work item to the build it was fixed in”

“Creating a work item from a failed build”

“Browsing the change sets included in the build”

Enabling these features for your team

The pretty pictures above are all great things to enable for the day-to-day user. However, those of you that have ever setup an automated build for a large project know that it’s a lot of work to compile, test, analyze, and package the end product. Typically, this involves many days or weeks of investment in customized scripts and tools.

So, another crucially important goal is that we wanted to enable the team keep their existing build scripts and tools. How do we bridge the gap between existing infrastructure and the first-class end-user experience described above?

The cornerstones of our solution include:

• Lightweight definitions of the building blocks for defining and driving a build
• A data model for build results
• A toolkit of commands that any build can use to inform Jazz about build activities and status
• A simple build engine

Lightweight Definitions

We don’t attempt to understand or define all the details about your build. The following lightweight elements are stored in the Jazz repository:

• Build definitions. These are definitions that can define different amounts of build detail depending on the build tools you’re using. For example, we provide an “Ant” definition template out of the box, but we also provide a “Generic” template that is basically just a set of properties that your build can use in any way it chooses.
• Build engine declarations. These declarations are merely identifiers for your concrete build engines (the actual programs running a build). We don’t attempt to connect to your build machines.

These definitions and engines enable Jazz Build frameworks and UIs to work with, and present your builds, but don’t force so many details that would constrain your choice of the concrete build engine and tools you wish to use.

Data Model for Build Results

Build results are stored in the Jazz repository. Jazz build results are composed of a flexible number of contributions (logs, downloads, links, compile and test info), allowing you to publish a result as rich, or as lightweight, as you’d like. The point here is that you may already have a significant presentation of your build results elsewhere on the web. Jazz build results don’t have to duplicate this data, they can simply link to it. Through the Jazz build result (even if it contains just an external link), traceability with work items and code is enabled.

Build Toolkit

We provide a toolkit of commands (in the form of Ant tasks) that any build tool can use to inform Jazz about build activities and status. Even the simplest build can use these commands to make the build come alive in Jazz. The team will see when the build starts, all the activities it performs, and its success or failure when it finishes.

Build Engine

We provide the Jazz Build Engine (JBE) out of the box for teams that don’t have an existing driver for their builds. JBE is a simple, yet robust, continuous integration build loop that can execute your build command based on a schedule or manual requests.

Stay tuned for more…

Hopefully, by seeing these design points, you will have a better understanding when you go to use and setup Jazz Team Build. In the last year, we’ve seen it used with various tools including Rational Build Forge, PDE Build, CruiseControl and custom internal tools. Keep an eye on Jazz.net for upcoming examples of using Jazz Team Build.

—
Ryan Manwiller, Jazz Team Build