For enterprise customers, the Enterprise Extensions feature of Rational Team Concert (RTC) both enhances their productivity and enables critical day to day tasks to be in a much more integrated way within the tool. There were several key upgrades to the Enterprise Extension functionality in RTC 6.0. Three that might draw attention are pointed out below:
Preconditions for Enterprise Extension
The pre and post-conditions available in RTC are a key mechanism in the ability to refine and configure the behavior of the product in a way that supports your organizations development and build processes. To some extent, the quantity and diversity of these pre and post conditions are a representation of the flexibility of configuration for the particular task in question. In version 6.0 additional pre-conditions have been added to support the Enterprise Extension tooling. These four new preconditions are described in a bit more detail below:
- Prevent delivery to promotion target streams - This precondition lets you deliver changes to target streams only for a promotion while also preventing you from manually delivering changes to streams. Having the ability to configure and control the flow of your source code—especially during promotion—is paramount to ensuring a quality build product.
- Prevent personal build from using wrong build workspace – Some preconditions, like this one, are there mostly as failsafe structures to prevent unintended consequences. This particular precondition prevents you from requesting a personal dependency build when using a wrong build workspace.
- Restrict concurrent promotions of work items – This precondition checks for a running promotion that contains the same work item. If a current promotion includes the same work items, the second promotion does not run.
- Require buildable subset in build – Many enterprise customers have a workflow based around changing and deploying as few files as necessary for their function. To support this type of workflow and to conserve MIPS, the concept of a build subset was introduced. This conceptual object in RTC allows users to define only a subset of the files they would like to build and then specify this grouping during their build. In version 6.0 a new precondition was added that enables you to require that a build is based on a buildable subset. You can specify the type of builds and optionally restrict specific build definitions to require a subset.
Overhaul of build subset functionality
In addition to adding the preconditions that support build subsets for enterprise builds, the build subset functionality saw a considerable upgrade for version 6.0:
- Originating work item persistence – Creating build subsets by hand can be tedious if there are a large number of files. Good development processes that encourage users to associate changes to work items that describe the changes they make provided a natural way to extract the target changes for build in an easy way. In version 6.0 the relationship between the work item from which the build subset was extracted and the work item itself is maintained. Traceability is one of the major strengths of a product like RTC—this addition simply furthers the depth of this traceability.
- Run Preview on Subsets – A very common use case, especially as the number of subsets grows, is to want to know what files are represented by this subset. The Run Preview option is now available from the context menu of a build subset. This is particular useful in the light of some of the additional features now included in the build subset editor.
- Build Subset Editor Overhaul – The build subset editor itself saw a pretty considerable overhaul in this release. Some of the highlights include: new ways to populate subsets, the ability to use subsets with new varying build definitions, the inclusion of build subsets in the process configuration editor and the ability to filter build subsets in several places in the tooling. The look, feel and general usability of the editor was improved greatly in this release.
Better integration with deploy tooling
Deployment automation has been the focus of much attention lately in the industry and in version 6.0, RTC added the ability to generate System z packages that can be consumed by IBM UrbanCode Deploy (UCD). This integration is surprisingly seamless. The package step itself does quite a bit of work to improve and streamline the creation process through introspection of the deployable artifacts chosen based on provided criteria. By then registering this package with the UCD server, the package can be deployed using the processes defined by UCD.