Using Rational Team Concert on Mac with Xcode (Part 3)

Warning icon This page describes a usage or software configuration that may not be fully supported by IBM.

Overview

This is the last article in a three part series covering how to use Mac and Xcode with RTC. Previously, you saw how you could transition your project from a single contributor to multiple contributors. Work items enable you to record the outstanding defects, tasks and enhancements as well as review each other’s changes. You have built up a collection of useful Jazz SCM CLI commands along the way.

In order to release your product one of the members of your team uses Xcode to produce a release build, runs the unit tests to make sure they are green, creates a disk image (dmg file) and creates a snapshot to record the state. It would be much better if this work was automated so that builds are created in a consistent way every time. It would be great if anyone can trigger a build when they need one and to have builds scheduled automatically.

Setting up automated builds in RTC

Xcode provides a set of tools to run headless builds and run unit tests but they have to be run on a Mac. The builds should run on a desktop computer or server grade computer that will not be taken offline very often and has constant network access to the RTC server.

Once you pick a computer to run your builds you can install the Jazz Build System Toolkit available on jazz.net via the RTC Downloads > All Downloads section. The build system toolkit includes a build engine that you run so that it continually checks for build requests from the RTC server. Once a build is scheduled the build engine will run what you have defined in your build definition and send the results back to the RTC as part of the build results.

The build engine needs to authenticate to the RTC server. In order to do this the build engine must log in using a build user account (e.g. macbuild) on the RTC server. It is not recommended that you use your normal user account for this. The build user will need access to your project area so it should be added as a member of your team. Contact your RTC server administrator to help create the user and add them to your project area. Make sure to protect the password to the account as it will have access to your project area and your code.

When you run the build engine it authenticates but then needs a build engine id on the server in order to identify itself for build requests. This can only be done using the RTC Eclipse client. Launch the Eclipse client and open up the Team Artifacts view like you did in the previous article. Expand your project area and go to Builds > Build Engines and right-click to choose New Build Engine. Leave the first page of the wizard with the defaults and click next. On the second page choose a unique identifier for your build engine and write it down for later. Make sure that the build engine type is set to Jazz Build Engine and click finish.

Create new build engine
New build engine
New build engine wizard
New build engine wizard
Build engine id
Build engine type and identifier

Before starting up the build engine there are some extra paths that should be added to your path so that the build engine can run Xcode build scripts when requested. If you have not already done so add the following path to the .bash_profile of your build account on your build computer (e.g. /Users/Build/.bash_profile).

  export PATH=$PATH:/Developer/usr/bin  

Once you have have added a build engine, a build user and added the special Xcode path you can start up your build engine on your build computer. Make sure to restart the terminal app to get the new path you added and run the build engine with this command.

  $ <fill_in_path_here>/jazz/buildsystem/buildengine/jbe.sh -repository https://myserver:9443/jazz -userId macbuild -pass xyzabc -engineId xcodebuilder  2012-06-08 09:47:21 [Jazz build engine] Running build loop...  2012-06-08 09:47:21 [Jazz build engine] Waiting for request...  ...  

The user id and password are the ones that this build user uses to authenticate against the RTC server. The build engine id should be the same as you created on the RTC server. You should start up the build engine interactively from the desktop and not through a remote shell or system startup task to make sure that the build engine has access to the Mac UI. There are certain tasks such as the unit tests that require access to the UI in order to work properly.

In the above example the build engine is run with the password provided as a command-line parameter. This is not the most secure way to do this. There is a special build engine command that allows you to generate a hashed password for your password and store this in a file. The file should still be secured properly but it adds an extra measure of security.

  $ <fill_in_path_here>/jazz/buildsystem/buildengine/jbe.sh -createPasswordFile ~/passwordFile  $ <fill_in_path_here>/jazz/buildsystem/buildengine/jbe.sh -passwordFile ~/passwordFile -repository https://myserver:9443/jazz -userId macbuild -engineId xcodebuilder  2012-06-08 09:47:21 [Jazz build engine] Running build loop...  2012-06-08 09:47:21 [Jazz build engine] Waiting for request...  ...  

The build engine is now ready to execute build requests but you will first need a build definition. Build definitions can only be created using the Eclipse client. Go to your project area in the Team Artifacts view, right-click on Builds and choose New Build Definition. Click next on the first page of the wizard. on the second page choose a build definition ID and select the "Ant – Jazz Build Engine" type. Ant is a popular XML build scripting language and will be used as the front-end script for this build. On the third page check "Jazz Source Control" so that the build will perform SCM related operations to get the latest code from the stream and load the contents into a build directory. Finally, on the fourth page check "JUnit Publishing" to enable unit tests results to be published.

Create new build definition
New build definition
New build definition wizard
New build definition wizard
Set build definition type
Set build definition type
Add source control option
Add Jazz Source Control option
Add unit test publishing option
Add unit test publishing option

Once you have created your build definition you can start editing it to add in the details of your build. For example, the build definition will need to have the path to your build directory where the Xcode source code will be placed and then built. Also, you can create your repository workspace on the server to accept changes from the stream, snapshot and load into the build directory.

Add build engine
Add build engine

Builds require a repository workspace to accept changes from the team stream, create snapshots and load your Xcode project code into a build directory. Also, people in the team can use it to compare build snapshots to find differences in the code. In the "Jazz Source Control" section you can create the repository workspace using the "Create…" button. Create the repository workspace from your team stream so that it flows with that stream and has an initial contents. When you are ready to save, make the visibility public and change the owner to the special build user for your build engine.

Jazz source control page
Jazz source control page
Add build engine
Create repository workspace

Once you have set the repository workspace in the build definition the build engine will need to know where to load the code on the local filesystem. Create an empty build directory on your build computer (e.g. /Users/Build/builddir) and provide this path in the "Load Directory" field of the build definition. It is recommended that you check the "Delete directory before loading" option to prevent cross-build contamination from an older build to a newer one.

The build definition needs an Ant script in order to execute the build steps after the source code has been loaded into the build directory. The Ant script will also inform the RTC server what activity the build is running as well as publish downloads, logs and test results. The Ant script setup options are in the "Ant" section of the build definition.

A sample zip is provided to demonstrate how to run an Xcode build and test. Unzip it into your development sandbox, edit them to suit the project names and settings for your project, check them in to a change set and deliver them to the stream. The build definition needs to know the location of the build script on the build computer after it is loaded into the build directory. Put this path in the "Build file" field (e.g. /Users/Build/builddir/MyXcodeProject/build.xml).

Set the Ant script path
Set the Ant script path

In order for the Ant script to communicate with the server it needs the build user credentials and the special password file. See the comments at the top of the build.xml script for more details. Although the build scripts are in your sandbox keep in mind that when the build executes them they will be loaded into the build directory on the build computer and not your sandbox. The password file should be on the build computer with permissions only for the build user to see it. Do not check it in nor share it with anyone else on the team.

If you want to run the build on a regular schedule like every weekday at 5:00pm then you can use the "schedule" section of the build definition. You can use this section to run the build continuously every x number of minutes if there are any new change sets delivered to the stream.

Working with builds

Now that the build engine, build definition and build scripts are in place you or anyone else on your team can request a build using your web browser. Go to the RTC server URL (e.g. https://myserver:9443/jazz), login using your normal user credentials (not the build user). Once you have logged in pick the project area and then click on the Builds > Build Definitions and choose your build definition.

Request a build

From the build definition screen you can see any previous builds that have run before and request new builds using the "Request Build" button on the upper-right. Once a build has been submitted it’s progress is shown in the build definition screen. You can click on the build to get a build summary.

Build definition screen
Build definition screen
Request build screen
Request build screen
Build progress
Build progress
Build summary
Build summary
Build downloads
Build downloads
Build logs
Build logs
Build test results
Build test results

Compare builds

Builds will pass and fail from time to time. Also, the application will occasionally break from one build to another. Builds are really useful for identifying the cause of the regressions because you can easily compare them to find the cause of the failure or regression. On the build definition screen check two builds and click on the "Compare Build" button in the upper-right. The snapshot compare screen has two tabs, which show the change sets that are in one build but not the other.

Compare builds from build definition screen
Compare builds from the build definition screen
Compare build results
Compare build results

Test changes with a personal build

When projects get large and it takes more than a trivial amount of time to build and run all of the unit tests. There can be times when you want to test out a set of changes to make sure that they don’t produce a build failure in the regular build but it would take too long to run on your development computer. Perhaps your development computer is a MacBook and you want to be able to sleep it in between meetings or leaving work at the end of the day?

Jazz Build has a special "personal" build option that you can use. Instead of using the repository workspace that is normally used in the build it can use the development workspace you use for your normal development activities. The workspace must have a public visibility and as long as you have checked everything in it will perform a build and run the unit tests against your changes before you deliver them.

To set your repository workspace as public you will need to use the Eclipse client. Launch it as described earlier, create a repository connection to your RTC server and find your repository workspace under My Repository Workspaces in the Team Artifacts View. Double-click on the workspace and change visibility to Public.

Repository workspace visibility
Change repository workspace visibility to public

You can request a personal build in the same way as a regular build except you check the "Personal Build" option and choose your repository worksace in the request build screen.

Request personal build
Request personal build
Compare build results
Compare build results

Summary

This final article in the series demonstrated how you can create Xcode builds and unit tests into RTC. Using a separate build computer builds can be scheduled by anyone on the team and/or scheduled automatically on a regular basis. The build results are recorded along with a downloadable disk image, logs, test results and a snapshot. Any user on the team can look at these results and and compare builds to see the changes in the code. Personal builds are available for you to try out changes in a build before delivering them to the team stream.

RTC can complement the Xcode IDE in the development of Mac applications. As your team expands beyond a single person RTC brings powerful collaborative features including stream management, work item tracking and builds. This series has only briefly touched on each of these areas for demonstation purposes. There are many more areas to explore.

About the author

Chris McGee is a member of the Jazz Source Control team. Previously, he worked on modeling tools for the Rational Software Architect project.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Feedback
Was this information helpful? Yes No 0 people rated this as helpful.