It's all about the answers!

Ask a question

RTC build: run builds and tests on different machines


Frank Schophuizen (19323126) | asked Nov 26 '08, 1:46 a.m.
With build support, RTC starts a build on a remote machine. This is a machine controlled by RTC and a build manager.

Does the build manager of RTC include facilities to spawn builds or test processes on another remote machine?

We need this because the build PC may not have all the software and hardware on board that are needed for the build and tests. Especially with dedicated hardware, the build cycle looks more or less like this:

- copy files from RTC to a remote build machine
- run build on the remote build machine
- check build result
- copy files to a remote test machine
- run an installation on the remote test machine
- check test result
- copy build results from remote build machine to RTC

Accepted answer


permanent link
Nick Edgar (6.5k711) | answered Jun 15 '09, 4:56 p.m.
JAZZ DEVELOPER
See also the blog post on BuildForge integration:
http://jazz.net/blog/index.php/2008/12/15/ibm-rational-build-forge-integration-is-now-available/

In the build scripts that drive the building of RTC itself, we do 'fork' separate builds for running tests, creating the install, and adding translation files.
This is done using the 'requestTeamBuild' and 'waitForTeamBuild' Ant tasks, with intermediate results copied to a shared directory.

For more details, see the Ant task reference at:
http://jazz.net/help/rational-team-concert/1.0.1/topic/com.ibm.team.build.doc/topics/r_ant-tasks.html
Frank Schophuizen selected this answer as the correct answer

3 other answers



permanent link
Martha (Ruby) Andrews (3.0k44051) | answered Nov 26 '08, 1:08 p.m.
JAZZ DEVELOPER
Hello,

What you describe is certainly possible with the Jazz Build Engine. You will need to provide a build script to do many of the steps, however.

In general, the Jazz Build Engine will look for requests to build, start a build record (called a build result) in the Jazz repository and complete the build result in the repository when the build completes. In addition, it can automate some steps that are common to most builds, such as fetching code that is stored within the Jazz repository. Beyond that, the build engine essentially runs a command (or a script) you define. The steps that the build takes depend on your build script.

Here is how the build you describe might work. Let's say that you want to use ANT to automate your build and you want to rely on the Jazz Build Engine to fetch your source code. You would install the Jazz Build Engine and build toolkit on your first remote machine. We will call this the build machine. In RTC, you would define a Build Engine and a Build Definition for your build. In the build definition, you would configure the Source Control support to fetch the source files you want the build to compile and you would provide the information an how to find your ANT script.

Next, you would write an ANT script that compiles the code, checks the build result, copies the code to another machine, and launches a script on the other machine to run the install and tests. The script on your build machine would then block until the install and test are complete.

The second machine we will call the test machine. On the test machine, you will install the build toolkit only (not the Jazz Build Engine). You would write an ANT script that would run the install and tests. You could use the tasks in the build toolkit to update the build result in the jazz repository with the build status, activities and test results from the script that runs the test. When the tests on the test machine complete, the script on the first machine can exit. The Jazz Build Engine will automatically complete the build result in the Jazz repository.

To see examples of using the Jazz Build Engine with a simple builds, see https://jazz.net/wiki/bin/view/Main/BuildExamples . You can follow one of the simple builds to get you started, then add the multi-machine aspect once you are satisfied with the basics.

Martha
Jazz Developer

permanent link
Frank Schophuizen (19323126) | answered Jun 09 '09, 1:46 p.m.

Next, you would write an ANT script that compiles the code, checks the build result, copies the code to another machine, and launches a script on the other machine to run the install and tests. The script on your build machine would then block until the install and test are complete.


This is not what I was looking for.

We are looking for a way that the build engine supports distributed builds, taking care of passing the build context to the other build machine, communicating progress, feeding back the results, etcetera.

On Windows using cmd scripts this is a nightmare. For example, we use xcopy does not support URI (e.g. \\server01), psexec does not pass the return code properly, transfering variables (e.g. within an XML context) to another machine is not possible, etc.
If the build engine would take care of this, it would be wonderful!

Maybe ANT already supports this, but I can't find much info on that.

permanent link
Martha (Ruby) Andrews (3.0k44051) | answered Jun 09 '09, 2:13 p.m.
JAZZ DEVELOPER
The RTC build engine will not do those things automatically. You may be able to write ANT scritps or tasks to do them, but I don't have the expertise to tell you how.

If you are looking for true distributed build support, you may want to look into Rational BuildForge. BuildForge can take care of finding a machine to run the tests, setting up the state information, communicating progress and displaying results. There is an integration between RTC and Rational BuildForge that would allow you to start builds from RTC.

If you want specifics about how you could use BuildForge to test, you can post your question to the BuildForge forum:
http://ibmforums.ibm.com/forums/forum.jspa?forumID=2100

Martha
Jazz Developer


Next, you would write an ANT script that compiles the code, checks the build result, copies the code to another machine, and launches a script on the other machine to run the install and tests. The script on your build machine would then block until the install and test are complete.


This is not what I was looking for.

We are looking for a way that the build engine supports distributed builds, taking care of passing the build context to the other build machine, communicating progress, feeding back the results, etcetera.

On Windows using cmd scripts this is a nightmare. For example, we use xcopy does not support URI (e.g. \\server01), psexec does not pass the return code properly, transfering variables (e.g. within an XML context) to another machine is not possible, etc.
If the build engine would take care of this, it would be wonderful!

Maybe ANT already supports this, but I can't find much info on that.

Your answer


Register or to post your answer.