Parallelizing Personal Dependency Builds

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:

devFlowIn 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:

concurrentBuilds Let’s briefly review the supporting infrastructure:

singleEngineFrom 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.

Gaining concurrency

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:

newBEnginenewCopyBEngineBecause 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:

concurrentPBuilds

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:

dupEnginesDedicating Engines to Personal Builds

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:

teamBEngineConclusion

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”.

adminProps

Advertisements

6 thoughts on “Parallelizing Personal Dependency Builds

      • I just tested and, as hinted by your post, this is a feature on Build Engine level, so it works on build engine level and works for all builds you could define in RTC.
        The filter prevents any build engine from picking up the build request in the first place. So you can dedicate some build engines for personal builds and others for integration builds.

      • Oh Ralph, you meant the build property … yes, that will generally work :).
        I was talking about the redundancy of build engines to get concurrency: as far as I know, for JBE based builds, in addition to increasing the build engines for concurrency (as I describe in this post), you will need to execute several instances of the JBE on the build server taking care of the metadata folders you configure, while here I am using just one running instance of the Build Agent on the build server and all engines reference it.

  1. Reblogged this on rsjazz and commented:
    Jorge just blogged about an interesting option to have separate build engines for personal builds and general builds. This allows you to provide capacities for both build types and control which engines perform which work.

    This is quite interesting, as it allows you to avoid situations where personal builds block integration builds from happening, just by setting a property in the build engine definition.

  2. Pingback: Performance Testing the Rational Build Agent – Strongback Consulting

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s