The use of Personal Builds allow a developer to verify if their checked in changes build successfully without impacting the team build, or waiting for a deliver-build cycle. In this forum post I want to discuss how to configure your Rational Team Concert deployment to allow the parallelism of personal builds by your developers.
I will use, as usual, the Mortgage sample from Money That Matters. Let’s take a look at the Development Stream basic configuration:
In the diagram we can see two users’ repository workspaces that deliver to the Mortgage Development Stream (Jorge’s and Dave’s), and a third one which is used by the Dependency Build Definition that builds the stream (in the sample called “mortgage.dev”).
In this scenario, in the event of both users triggering personal builds one of them will get queued waiting the engine to be freed:
From the previous diagram we can identify that we have the Build Definition being supported by a Build Engine which uses the Build Agent running on the mainframe. The first personal build request will be served by the engine, and the second will get in Pending state, waiting for the engine to be available to process it.
Continuing with the scenario, to allow Dave and Jorge users to build their changes at the same time, we need to increment the “pool” of build engines that are serving build requests. The easiest way is to create a new Build Engine copying the existing one:
Because this new Build Engine is a copy of the existing one, it will be supporting the original definition “mortgage.dev”. If you are not making a copy, make sure you add support to the Build Definition. Now if we repeat the previous test where both of the sample users request personal builds at a similar time they can now be executed concurrently:
Therefore, we need the same number of build engines as the parallelism we want to support, and these engines can point to the same Build Agent installation. The following diagram outlines this modified build logical infrastructure:
The potential coincidence of personal build requests and a team build for the same definition will depend on the schedule of the team build, your teams distribution and the work needs. So even though collisions might not be frequent, you can find your team build queued because of the personal builds being under execution. To avoid such situations, you can configure whether a build engine will only serve personal or team builds. The property is called “requestFilter” and it accepts the values of “personalBuild=false” (no personal builds served by the engine) or “personalBuild=true” (if the engine will just serve personal builds).
Following the sample scenario, we can add a third copy of the “jke.rba.engine.dev” Build Engine with the referred property to dedicate it to team builds:
In this post I have discussed how you can configure several build engines definitions to allow concurrency processing of personal dependency build requests, and how to also make sure that your team build is not impacted by these personal builds.
Note that there is a server property that you may need to consider tuning in your infrastructure, this is the “Asynchronous Task Pool Size” under “com.ibm.team.repository.service.internal.AsynchronousTaskSchedulerService”.