Who says work can't be fun? Just the other day some of the PacGenesis team in Austin decided to put their collective heads together and have a docker nerd out session. Aside from this horrible picture, now we've got Docker images and docker files for UrbanCode Deploy and IBM's Jazz ALM solution!
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.
To support better integration across the product lifecycles several Global Configuration Management three main updates were made in RTC version 6.0:
- Personal streams – The tightly coupled integration between and among the jazz products is one of their great advantages. To further invest in this integration the concept of a personal stream has been introduced in version 6.0 of RTC. This will allow users to create and remove links that span project areas and access change sets across project areas without changing the global stream.
- More granular permissions – Permissions can now be defined for creating and modifying components, streams and personal streams.
- New roles – Three new roles have been added to the default process template: Contributor, Baseline Maker and Configuration Lead adding more fined tuned role based behavior to an already robust system.
Build Report Editor
As teams adopt and begin to invest more heavily in Rational Team Concert (RTC), builds and their associated build results become a type of currency in their organization. The build results in particular are more than a little valuable both for debugging build problems, but also as input to post build processes and for communicating the technical content of the build. The ability of this build report to effectively communicate what got built, where it got built and what perpetuated these actions is critical. In version 6.0 a new embedded build report editor was introduced that allows users to browse build result details with a considerable set of tools—pagination, search and sort—to make this process easier.
This editor also provides a much more interactive experience than had previously been available in this area of the product by providing links to a variety of build artifacts. Again, this is a visibility and traceability boon for users who want to know exactly what happened with their build and be able to dive easily into the details without sacrificing a valuable and meaningful summary.
The full list of changes for the build result editor are too detailed to enumerate here, but it’s certain to say that this would be an area to explore in the latest version of RTC.
We set out to do a four part series on the new function available in the upcoming release of RTC and quickly discovered just how substantial this release was. Given that, we hope this series could at least then help communicate and give interested parties a small taste of some of the great new changes available in Rational Team Concert version 6.0. The development team has clearly invested a significant amount of time and effort pouring great new function into this release. There’s no way we could capture all of these worthwhile line items.
As one last word, we would encourage anyone interested in getting more detail on the full list of included line items to explore the New and Noteworthy section of the jazz downloads section for Rational Team Concert!
Some might consider Source Control to be the backbone of any SDLC solution. Without a robust source control solution the integrity of your source code and the validity of your historical data are both at stake. As we continue our discussion of new features introduced in Rational Team Concert (RTC) 6.0 we should mention some of the changes that have been made to the source control functionality in the product.
Conflict resolution of moved projects
Conflict resolution is one of the most critical aspects of source control management and possibly also one of the most troublesome. It’s a task that can be tediously difficult to get correct while also being mission critical to code function. In RTC you can move a project folder from one component to another by using the Teamà Move In Repository context menu. This can be problematic when another user with the moved component added to their workspace then makes subsequent changes to the contents of the project folder. They will obviously get a conflict, but the conflict shows these changes as being Deleted—which, while conceptually is partially correct, could be misleading. If handled incorrectly this could easily lead to a lost update issue.
In version 6.0, providing users with an “Apply to Component” menu option from the conflict resolution editor mitigates this risk. Under the covers this applies a patch to the project in it’s newly parented component and resolves the issue as a with the gap editor. While this may on the surface seem to be a trivial addition this type of problem can be catastrophic from a functional standpoint and resolving the conflict can be cumbersome. By providing this shortcut the resolution is more direct and understandable.
Configuring default workspace names
One seemingly minor improvement in 6.0 is the ability to configure a pattern for workspace names in your project area. While this may not provide a big functional spark, it certainly has workflow efficiency implications. For avid users of RTC, creating workspaces is a task that happens often. Depending on the particular organizational workflow, users may be working on several workspaces simultaneously or even creating several workspaces each day for their work.
The high volume nature of workspace creation can lead to inconsistency in naming convention and difficulty finding/locating workspaces in the project area. By establishing a workspace name pattern as part of the project area configuration standardization of workspace names can be implemented and workspaces names can be more meaningful.
Expanding custom attribute functionality
Customization is King! It’s nearly impossible to create a one-size fits all product that will give every organization exactly what it needs in every situation. Therefore, the ability to be customized is a more valuable quality in an SCM solution than sheer option volume. RTC has customization built into its core. With version 6.0 the ability to define custom attributes has been expanded to include source control artifacts like baselines, snapshots and streams.
The major advantage of this change lies in the ability to enhance visibility, traceability and communication about version control artifacts. By defining a custom attribute on a snapshot, for instance, that describes the purpose or target of that snapshot (for example, “FVT Deploy Snapshot” to indicate this snapshot was intended as a functional test target) the team can then define queries that use this attribute to communicate across the wider organization. Additionally, since custom attributes in version 6.0 can be queried by the CLI, this function has far reaching impacts and applications beyond the eclipse or web client.
Component Hierarchy Organization
In the upcoming release of RTC, IBM has added support for many-to-many parent-child relationships for components. This means that a component can have subcomponents and a single component may be shared by multiple parent components. This is a relatively fundamental change in how source control behavior manifests itself in RTC and has some compelling use cases:
- Codifying dependencies – In current versions of the product, component dependencies are loosely defined. While there are ways to organize your artifacts that can mitigate this issue, component hierarchies gives users a straight forward way to indicate that one component depends on another and this dependency is broadcast across the project area fostering better cross functional knowledge.
- Traceability – Since changes to this structure would be tracked like any other artifact change in RTC, changing dependencies would be visible in the artifact history. This additional level of traceability has tremendous value for organizations with audit concerns.
- Large-scale reusability – For organizations with many components that follow a nested function approach, the ability to communicate and understand functional pieces at different levels is important. By having the ability to define component hierarchies in a nested fashion, you also gain the ability to understand and add function to workspaces at each of those levels.
One obvious downfall of the many-to-many nature of this change is the capability to introduce a circular dependency. These dependencies are allowed, but marked in the product for potential resolution. One additional note about this function—while it is fully functional and available in version 6.0, because it is not yet supported for Visual Studio Clients it is disabled by default. You must manually enable the function to use it until it is available on all platforms.
Again, by no means is this a comprehensive list of Source Control modifications made in version 6.0. It does represent a list of impactful changes, however, that consumers should plan for and incorporate into their evaluation of this release.
Fans of Rational Team Concert (RTC) have been anxiously awaiting the release of RTC 6.0—the wait is over! For a larger release like this one, it’s difficult to summarize all the changes that have gone in. Even more so, it’s difficult to decide which changes to highlight as pivotal and which ones may be considered minor. In this four part series we’ve tried to highlight a few items planned for delivery in RTC 6.0 worth noting.
Planning has always been one of the arch stones of the RTC story. It’s no surprise then that IBM made this a focal point for development in version 6.0. In version 5.0.2 of the Rational Team Concert product IBM officially introduced the Quick Planner view (this was release as a tech preview in version 5.0.1). This feature builds on the native planning capability already available in the product by making it easier and faster to manage your projects in an task-oriented agile way. Work item organization and creation has been streamlined with this feature to accelerate project workflow. In version 6.0, there were a myriad of updates to this feature. The list below highlights just a few of these updates to the Quick Planner:
- Ability to customize filters with any enumeration-type attribute including custom attributes
- Usage of logical operators in attribute filters.
- Extension of quick-create functionality to include any enumeration-type attribute. This would allow to quickly and easily create items with a particular enumeration value type.
- Optimizing the QP viewer for mobile devices
- Support for the Found In attribute
- Predefined reports from the Jazz Reporting Service are embedded in the QP view
- Task breakdown view allows you to add existing tasks as children quickly.
The volume of improvements to this feature will only help improve end user uptake and clearly represents an effort to migrate some of the most useful features of the planning functionality from the full feature client into the web-interface while simultaneously striving to maintain usability.
To that end, the other major Planning related change you can expect to see in version 6.0 is the removal of the Plan editor in Milestone 11 of this release from the eclipse based client. All planning going forward from this release must be done using the web-client. For traditional users this could represent a pretty significant paradigm shift, especially in organizations looking for a modernization solution for legacy development groups. The shift to a web-based planning solution, while substantial for some, is generally a much more approachable and standardized presentation solution. It’s worth taking this change into consideration when planning your potential forward migration.
While this is not a comprehensive list of the planning changes made in the upcoming release these are two of the major line items. It’s encouraging to see the continued investment in Planning features and functionality—keep up the good work!