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.
The roperty requestFilter can be set on a build engine. It accepts the values
- personalBuild=false which filters out personal build requests and prevents the engine from picking them up
- personalBuild=true which filters only for personal build requests
By providing several build engines (at least two) for a build definition with these filters set, you can control which build engine will pick up and serve which build request type.
This works for all types of builds that is controlled by the RTC “Request Build” mechanism and performed with a Jazz Build Engine, because the functionality is provided by the Jazz Build engine itself.
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.
View original post 495 more words