IBM Rational Jazz Source Control and Build Management Tool Tutorial

By Kamila

By Kamila

Kamila is an AI-based technical expert, author, and trainer with a Master’s degree in CRM. She has over 15 years of work experience in several top-notch IT companies. She has published more than 500 articles on various Software Testing Related Topics, Programming Languages, AI Concepts,…

Learn about our editorial policies.
Updated January 7, 2025

Here is the complete tutorial on Jazz Source Control and Build Management for your benefit:

Jazz Source Control is a repository in RTC that can hold the source code and any other artifacts like documents or HTML files or any text files. Jazz source control management comprises of several components like components, changesets, streams, repository workspaces, etc.

In this tutorial, we will learn more about the components and functions of Jazz Source control along with Build Management module of RTC.

NOTE: This tutorial has many images so allow it to load properly. 

In this tutorial, we are going to take an in-depth look at “Jazz Source control” using “IBM Rational Team Concert” and it is based on version 6.0.2.

Jazz Source Control and Build Management

IBM RTC Jazz Source Control & Build Management

Introduction to IBM Rational Team Concert

As mentioned above, IBM Rational Team Concert (RTC) is one of the key components of IBM Rational CLM solution.

Today with ALM solution, project teams are looking at a solution which is integrated with execution. IBM Rational Team Concert helps Project Managers and the Developers to maintain the few artifacts within one single repository.

The artifacts are:

  • Work Item Management
  • Project Planning (Supports Agile Scrum and Waterfall)
  • Software Configuration Management (SCM)
  • Build Management

All the above components are well integrated to provide complete traceability of work that is performed from a development perspective. Now, let’s take a look at some of the concepts involved in Jazz SCM.

Any development team consisting of multiple members works with a large base of source code for an application that is being developed. Each team member works with the same source code, changing one or more files to work on a new feature or to fix a defect. The team member will check if the changes are correct and then share those changes with the rest of the team in the common area.

At the same time, other team members will work on the tasks assigned to them and make changes to the source code. So a source control tool helps in organizing the team’s source code or documents, tracking them and sharing changes to a common area thereby assisting the team to complete the tasks assigned to them.

In my previous tutorial, we saw how work items (like Story, Task, Defect etc.) hold important project information. In extension to that, these Task items will now be linked to the changes in source code.

Components of Jazz Source Control

Jazz Source Control is a repository in RTC, which can hold the source code and any other artifacts like documents or HTML files, or text files. This repository is managed by Jazz Team Server and is accessed using a URL which we will see in this tutorial.

Let’s look at the components involved in Jazz Source Control and how we will utilize it.

#1) Change Set

A Changeset is a collection of files and directory changes that are typically grouped together. In the following sections, you will see how multiple changes to the source code are grouped into a changeset.

#2) Stream

A stream is used to store the entire team’s changes. Typically when all team members make changes to the source code, they commit or deliver the changes to the project’s mainstream. Before they deliver the changes, they have to assign the changes they made in the source code or any artifacts to a Task work item that a team member is assigned to.

#3) Component

A component holds all of the artifacts which include the source code and any other project artifacts.

#4) Repository Workspace

A repository workspace is an area where you can view and modify version-controlled artifacts. The creation of a Repository Workspace is a must for every member working on source control artifacts.

If there are 10 members working on the Jazz Source Control repository then each one of them should create at least 1 repository workspace to work on version-controlled files.

How Do Jazz Components Work?

Let’s look at the workflow of how the above components work together as integrated.

The flow starts from left as shown below with the first developer making the changes in his development IDE like Eclipse or Visual Studio.Net to the source code and then checks-in the changes to the repository workspace and DELIVERS the changes to the project’s main shared work area called the Stream.

The second developer, while working on his source code changes, will ACCEPT the changes into his own workspace. While doing so, if there are any conflicts in the same line or multiple lines then he has to manually merge those changes.

IBM Jazz Components

Jazz SCM Usage

In order to work on Jazz SCM, users must do the following: I have taken the above scenario and explained to 2 users working on the same code base. In this tutorial, I am using a sample Java web project code in Eclipse IDE. The same procedure can be followed in Visual Studio.NET for the .NET code base as well.

User 1 Activity

  1. User1 shares the project with Jazz source control
  2. User1 makes changes, checks in, and delivers the changes to the STREAM project. Remember that no explicit check-out is required. When the user makes changes, it is considered at checkout.

Let’s now look at how the above 2 steps are done in Eclipse IDE as User1. So the first user logs into the RTC project area and switches to the Java perspective.

A sample HelloWorld Maven web project has been created and will be uploaded to Jazz source control for the team to work on.

(Note: Click on any image for an enlarged view)

Sample Project Uploaded to Jazz Source Control

Share project with Jazz Source Control as User1

#1) User1 logs into the RTC project area and opens the Java perspective where the Maven project will be visible in the Package Explorer view. To share the project to Jazz source control, right click on the project and then select Team=>Share Project

RTC Share Project

#2) Select Jazz Source Control and follow the remaining steps to complete the upload to the Jazz repository

Select Jazz Source Control

Create a new repository workspace for User1

Create a new repository workspace

Select the Project stream. Remember that the stream and component were created by default when the RTC project area was created. You can create your own stream and component as well. For this exercise, we will use the default ones created already.

Select a Project Stream

Ensure that the project is shared with Jazz source control is selected. Click Finish.

Share Project in Jazz

#3) You can now see that the User1 Workspace is associated with the Maven project in the Package Explorer which means the project is now under Jazz source control repository.

Workspace associated with the Project

#4) The project is shared to Jazz source control but is not yet visible to other team members. For this, a Deliver operation should be done. Go to Pending Changes View and you will see an Outgoing folder. Right-click on that Outgoing folder and select You will see the change set under the Outgoing folder. It can be a comment or a Task work item assigned to the developer

Project Delivery Operation

#5) The project is now available in the project stream. So other users can now create a repository workspace and make changes to the version-controlled project in their own local Eclipse workspace

Project Visibility

User2 Activity

As User2 will be accessing the repository for the first time, the following actions need to be done:

  • User2 logs into the RTC project area
  • Creates a repository workspace and downloads the projects uploaded by User1
  • Initially, the project will be downloaded to the local machine from the jazz repository to make changes. Hence for the first time, User2 does not need to ACCEPT any changes. But subsequently, the user will need to ACCEPT the changes
  • User2 does the changes and then delivers those changes to the stream.

#1) User2 creates a repository workspace as shown below. Right-click on the stream and select New =>Repository Workspace

Create New Repository Workspace

Enter a name, such as User2_Workspace and then click Next to follow the remaining steps.

New Repository Workspace

Select Repository

Read Access Permission

Components to Add

Click Finish to start downloading the Maven project from the repository to the local machine eclipse workspace.

Load Eclipse Projects

Load Repository Workspace

Click on Finish

Loading Repository Items

#2) Now you can see the project which is linked to User2_Workspace

Project Linked to User Workspace 2

#3) Open the index.jsp file and make some changes. Remember there is no checkout and this change is done as User2. SAVE the file after making changes to it. At the bottom of the Pending Changes view, you will find an Unresolved folder.

Unresolved Folder

#4) If in case you want to undo the changes, then you can do so by right-clicking on the Unresolved folder and selecting If that is not required, then proceed to the next step.

Undo Changes

#5) Now right click on the Unresolved folder and select Check-in All.

Select Check in all

#6) Assign a TASK work item to the changeset and deliver the changes to the stream. Right-click on the change set, which shows as <Enter a Comment> and select Related Artifacts =>Associate Work Item

Related Artifacts

Select the Taskwork item assigned to User2 and click OK

Select Work Item

#7) You can now see the changes associated with the Taskwork item and can now deliver the changes to the stream.

Deliver changes

CLM Default Component

#8) You can also view the history of changes to any file. Right-click on the file in the Package or Project Explorer, and select Team=>Show History

Show History

History of Items

#9) You can revert back to any previous version by right-clicking on any previous Version ID and selecting Load. After this, you will need to check-in and Deliver as usual.

Select Load

User1 Activity

Back in the User1 workspace, since User2 has delivered the changes, User1 will now see the changes as Incoming. Right-click on the Incoming folder and then select Accept.

Accept incoming folder

The changes done by User2  is now populated in the User1 workspace. So User1 workspace is up to date on the Jazz repository.

Up to date User 1 Workspace

As per User1, we can now modify the second line in the <body> tag to produce a conflict assuming that even User2 does a change on the same line.

Modify Body Tag

Usually save the file as Check-in All, Assign to a Taskwork item, and Deliver the changes to the stream.

User2 Activity

User2 will see the changes in the Incoming folder. But at the same time User2 also modifies the same line.

Change in Incoming folder

Save the file. Right-click on the unresolved folder and select Check-in All

Unresolved Check in

Assign a Taskwork item before delivering. Right-click on the changeset titled <Enter a Comment> and Associate a Work item. Click on OK once done.

Task Work

Select Work Items

Right-click on the Outgoing folder and select Deliver

Outgoing Folder

Please note that the changes cannot be delivered as there is a conflict. We need to resolve the conflict and then proceed with Deliver. Click on OK

Deliver Failed

To resolve the conflict, first of all, accept the Incoming changes. Right-click on the Incoming folder and then select Accept

Incoming Folder

In the Auto-Resolve box, select the Resolve Later option

Auto Resolve conflicts

Double-click on the index.jsp file shown in the Unresolved folder.

Pending Changes

Right-click on the index.jsp file and select Resolve with mine. This option will retain the changes made by the current user which is User2. Resolve with Proposed will update the file with the incoming changes done by User1.

Resolve with mine

Confirm resolve with mine

Click on Yes to proceed and then select the option Resolve as Merged on the right-hand side.

Resolve as merged

Now right click on the change set below the Outgoing folder and then select Deliver

Outgoing change set Accept

Now login as User1 and Accept the changes from the Incoming folder.

Build Management

IBM Rational Team Concert supports build management as a logical extension to the version control activities which were explained above in this tutorial. Multiple team members deliver their changes frequently, preferably on a daily basis, and each of these integrations is verified by an automated build to detect any defects or errors as quickly as possible. This leads to the concept of Continuous Integration. The automated build is normally done on a dedicated build server and not on a developer machine.

To get started with build management activities in RTC on the build server, you will need to download and install Build System Toolkit using the IBM Installation Manager. For version 6.0.2 it is available in the Jazz.net download site.

Installation instructions can be found on this page.

To define and run any build you will need the following 2 build artifacts

  • Build Engine which helps to run the defined build. This will be available once the Build toolkit is installed
  • Build Definition which helps identify any build script like ANT or Maven

All Build Management actions are done on a dedicated build server and a separate repository workspace has to be created for the build. Do not use any existing developer repository workspace.

Start Build Engine

In RTC, create a Build engine as shown below. Right-click on the Build Engines folder and then select New Build Engine

Create Build Engine

New Build Engine

Click Next>

Enter your ID and select Jazz Build Engine and click on Finish

Jazz Build Engine

Click on Save on the Build Engine screen

Maven Build Engine

Start the Build Engine

To start the Build Engine, go to the directory where it is installed and then run the jbe.exe program found in the build toolkit eclipse directory

D:\IBM\TeamConcertBuild\buildsystem\buildengine\eclipse

Run the program from the command prompt

Maven Build Engine

Replace the values as per your server details

Replace Values as per server details

Create a Build Definition

Right-click on the Builds folder and select New Build Definition and click on Next

Create a Build Definition

New Build Definition

Enter an ID and select Maven – Jazz Build Engine as the build template. Click Next

Maven- Jazz Build Engine

Select Jazz Source Control and select Finish

Select Jazz Source

In the Overview Tab of the Build Definition, add the Build Engine created earlier and then click OK

Add Build Engine

CLM Build Definition

In the Jazz Source Control TAB, select or create a new Build Workspace and enter the load directory. This is the directory where the project will be downloaded and the build will be done to generate the WAR file. Each time the build is done, it will be deleted and the latest project content will be downloaded for the build.

Create a Build Workspace

Just below the same TAB, you will see the option where the latest changes will be accepted before any new build and only if there are changes the build will be made.

Accept changes in new build

In the Maven TAB, enter the location in the pom.xml file. The project will usually be downloaded to the load directory. So the pom.xml location would be D:\LoadDir\HelloWorld-Maven

Enter goal as install.

Enter the Maven Home Directory without the \bin

Save the Build Definition.

Project Location

Request a build

For the Team Artefacts view, right-click on the build definition and then select Request Build.

Team Artifacts

Click on Submit.

Request Build

The Build result is shown as completed successfully and the WAR file generated in the target directory will be shown in the package explorer.

Complete Build Result

Conclusion

In this tutorial, we have seen how to use the version control module within IBM Rational Team Concert and how work items play a very important role in the traceability of the source code.

The most important part of the SCM activity in RTC is that it is completely integrated with Build Management which defines the concept of Continuous Integration.

We also learned about the Build Management module of RTC which accepts the latest changes from the Jazz SCM repository and performs the build.

In my next tutorial, we will see an extension to this building activity which is – Auto Deploy using another IBM tool called IBM Urbancode Deploy.

Stay tuned!!!

Let us know your thoughts/suggestions in the comments section below.

Was this helpful?

Thanks for your feedback!

Recommended Reading

  • Source Control or Version Control in DevOps

    Source Control in DevOps: In our last tutorial we saw about DevOps practice based on Agile Manifesto. Here, we will see more about Source Control or Version Control in DevOps. One of the key factors that the success of DevOps depends upon is the ‘Source control’.                   Further Reading=> Complete…

  • IBM RQM integration with RFT

    In this tutorial, we will look in detail at IBM Rational Quality Manager (RQM) integration with Rational Functional Tester (RFT). IBM Rational Quality Manager is the Test Management solution that is a part of the IBM Rational CLM. It offers the capability to create Test Plans, Test Cases, and Test…

  • IBM Rational Team Concert tutorial 1

    IBM Rational Team Concert (RTC) is one of the key components of IBM Rational CLM solution which helps the project managers and developers in maintaining certain artifacts within one single repository. In this tutorial, we are going to take an in-depth look at Defect Management using “IBM RATIONAL TEAM CONCERT”…

  • Learning Basics of Rational Robot

    Rational Robot is an automated functional, regression testing tool for automating Windows, Java, IE and ERP applications under windows platform. This article should be a good start for those who wants to learn Rational Robot test automation tool. Read on for Rational robot tutorial with trial version download and resources.

  • Introduction to IBM Rational CLM

    IBM Rational CLM exhibits the traceability relationship between requirements and development thereby enabling the business analyst and project manager to know the status of the set of business requirements and the planned work items. In short, IBM CLM is a combination of Requirements Management, Change & Configuration Management (CCM), and…

  • IBM RTC Advanced Work Item Customization

    This tutorial - "IBM Rational Team Concert Advanced Work Item Customization" - completely explains the customization according to the user need thereby defining the possibilities of customizing work items, editor presentations, and work item attributes. => Also Read IBM Ration Team Concert Defect Management Tutorial #1 here. For work item…

  • Best Source Code Management Tools (1)

    Here, we review top Source Code Management Tools, and determine the best Source Code Management software to track application code changes: Source code management tools, also known as version control or revision control systems, are used to track changes to application code and allow teams to collaborate on the same…

  • IBM Rational Doors NG

    IBM Rational DOORS Next Generation (NG) is an integral part of CLM which helps a Business analyst to capture, analyze and manage the functional and non-functional requirements effectively. In my experience, I have also used this requirement management tool to collaborate with customers on the requirements captured to provide approvals…


5 thoughts on “IBM Rational Jazz Source Control and Build Management Tool Tutorial”

  1. Well I have not done any changes to POM.xml. It is the standard one which is generated through the the J2EE maven project. Though if you need to change you can add instructions about the code analysis using Sonarqube and also JFROG artifactory instructions if you need to push the WAR or EAR files to the repository.

    Reply
  2. Good tutorial.
    Unfortunately, RTC is very archaic compared to GIT its integrations and ecosystem, there is no reason to use it in modern software development, aside from the obligation imposed by long living contracts in slow to evolve big companies.

    The level of possibilities and practices with distributed version control systems (GIT is dominant), simple speaking: it can’t even compare. RTC served well its purpose and I currently using it, but time to retire it.

    Reply

Leave a Comment