Building

This topic describes how to build the project so that it includes the changes that you have built and tested locally. The release engineer typically completes this task.
This graphic
is a workflow diagram that shows the steps that make up the build
task. Click this area to get information about completing plan items Click here to get information about elaborating plan items Click here to get information about detailing requirements Click here to get information about developing Click here to get information about testing Click here to get information about requesting a team build Click here to get information about reviewing build results Click here to get information about tagging build results

The purpose of the team build is to build the entire project, which you can then deploy for testing. The team build includes all changes that developers have delivered to the stream.

Before you begin

To include the latest changes in a team build, the developers must have delivered their changes to the stream. The team build uses the files in the stream. Before delivering changes to the stream, developers should build and test their changes in their repository workspaces.

Step 1: Request a team build

In your role as release manager, coordinate the timing of builds with the rest of the team. Within the build definition, you can schedule the build to run at specific times. For example, you might want to schedule builds to run once a day at night so that the builds include the changes that developers have delivered during the day. You can also start a build at any time by request.

Step 2: Review the results

After you start a build, monitor its progress in the Builds view in the IBM® Rational Team Concert® client for Eclipse IDE or on the Build Queue page of the web client. You can see how long the build has been running and its estimated completion time. You can refresh the display to get the latest status. After the build finishes, review the results of the associated unit tests. If a test fails, contact the appropriate developer to investigate the failure.

Step 3: Tag the results

After the build finishes, apply one or more tags to the results to indicate the quality of the build. For example, if the build fails some of the associated unit tests, you might want to apply a failed-tests tag. If the build passes all unit tests, apply a tag that indicates that it is ready for system verification testing.
Supporting tasks:

Results

By completing this task, you have built a new version of the project, which includes the latest changes developers have delivered to the stream.

What to do next

The testing team deploys the new build and tests it.

video icon Video

Jazz.net channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community

Jazz.net
Jazz.net forums
Jazz.net library

support icon Support

IBM Support Community
Deployment wiki