PacGenesis- Rational CLM Experts focused on EM
scottpecnik 2700006QND 282 Visits
If you're thinking of adopting RTC EE within your organization, you're likely already aware that it can be a daunting task. Whether you're evaluating RTC as a possible solution or looking to grow your existing RTC implementation from distributed to mainframe, there's a lot of work to be done.
The benefits of a single tool for all of your developers is obvious. Getting there, is not. I'm not here to sell you on a tool or a wistful dream, I'd prefer to talk facts. We've successfully implemented RTC EE, and here's how we did it:
First, the obvious truth is that an adoption like this requires cohesion between three main focuses:
Here we'll discuss only the technology side of the effort and we'll stay high level in order to maintain interest while getting our point across. Let's dig in, below are the pieces that make up the puzzle in no particular order:
As you can see, along the way of our success, we've built many utilities and solutions that allow us to successfully migrate our customers to RTC cheaper, easier, and faster.
If you have any questions or would like to hear more about any one of the above tasks, leave a comment.
We'd be happy to elaborate further in a separate post, just tell us what you want to hear!
Everybody knows that a service-oriented architecture (SOA) is the sought after design when building an application. In my opinion, regardless of application size, modularity should be practiced at all times. I'm more than guilty of thinking too much before I code, but architecture is important to me, and if my own experience bodes true, you never know how long that line of code you always meant to go back and clean up will remain in production.
Having a SOA is critical to anybody that wants to stay relevant in today's technical landscape. Single-sign on currently has a staggering amount of momentum, and RESTful services are becoming a necessity for any new web site that wants to call themselves even the least bit technically savvy. The question now stands, with all of this programmer collaboration and shared services, how do we manage it from the perspective of source control management (SCM)? While I'm a proponent of encapsulation, I believe that openness has an equally important seat at the table. Large development organizations should be able to share logic across lines of business, application groups, and teams without boundaries. You may have already guessed it, but RTC has the solution for this growing problem.
In a previous post called Scaling a Plan, we discussed the ability to associate RTC change sets with work items in a different project area and CCM. This feature provides boundless scalability for the work item management (WIM) features of RTC.
For large multi-national organizations with millions of lines of code contributing to hundreds of applications, there exists the ability to flow changesets across repositories. This provides tremendous opportunity to manage multiple branches of the same source whilst maintaining control of the development process through RTC's ability to manage changes across project areas and CCMs.
In order to leverage this functionality, one must simply create a repository workspace in a CCM that flows to a stream in another CCM. Let's walk through it. Below we have a screenshot that shows two repository connections, each to a different CCM connected via a single Jazz Team Server (JTS).
Each CCM has a project area called Accounts Receivable that in this case presumably represents the same application managed in different regions.
Here are the project areas expanded, you can see that the North American Dev team has created a few components in their stream.
Sharing changesets across the repositories is simple, and the basis for scaling an SCM. We'll start by creating a repository workspace off of the stream in the Accounts Receivable project area in the North American Dev CCM.
On the first page of the wizard we'll select our stream as the flow target.
Next, we'll give our repository workspace a name. Remember the name is arbitrary, lest your organization maintains a proper naming convention.
The below wizard page is where the magic happens. Instead of choosing the current CCM as the owner of the repository workspace, we'll place it in the South East Asia Dev CCM. This will allow us to flow our changes across the two CCMs.
Finishing the wizard and tracking the newly created workspace in the pending changes view, you'll see the following. You may have also noticed that the components and changesets in the North American Dev CCM have been replicated across to the South East Asia Dev CCM.
Skipping ahead a few steps, a developer working in the South Ease Asia (SEA) CCM can now deliver changesets to the stream in the North American (NA) Dev CCM. For the sake of brevity, we've created a new Java project via the SEA repository workspace and delivered it. Below you can see that change as an incoming change to all developers working in the NA CCM.
There you have it, flowing changes across CCMs.
As companies have evolved and borders broken down, the redefined desire for globalization has become the "globally integrated enterprise". The stages of this evolution have undergone great transformation, including brief stops with the concepts and practices of both national and multinational corporations. What the globally integrated enterprise represents is one unified front; one company, no matter how large and/or geographically removed from itself adhering to the same standards and business practices.
It used to be that developers sat around the same table, talked shop by the coffee machine, and occasionally got hit by a nerf dart in the middle of a spontaneous raid. While this environment still exists, it's no longer a necessity. Development teams have since branched out to different offices, states, countries, and even continents. What makes this type of shift possible is the introduction and improvement of development tools focused on Application Lifecycle Management (ALM). With the ALM process we get realtime planning, lifecycle traceability, continuous build, automated testing, and much more. One such tool that facilitates this type of process is IBM's Rational Team Concert.
Let's consider a large globally integrated enterprise that is implementing a company wide development plan across all groups. This means that all developers, distributed or mainframe, North America or Asia, will adhere to the same requirements and release cycle. Considering several thousand developers, scalability is a major concern. In order to address this, we can leverage the RTC ability to distribute Change and Configuration Management (CCM) systems. This will allow them to scale their repository across multiple machines, while still maintaining interconnected addressability.
By setting up an environment with distributed SCM and change set association, we're able to demonstrate the ability to associate work items from a project area in a different CCM to changesets in another. This allows for a global plan with endless reporting and project management possibilities. Let's see it in action.
The screenshot below shows two repository connections, one CCM designated for planning and another for SCM.
Once our CCMs are configured, we can create plans and work items in the Planning project area with development happening in other project areas across different CCMs.
When a North American Accounts Receivable developer makes a change to source, upon delivery he will associate that change with a work item in the Planning project area that exists in a different CCM.
The process is straightforward. Instead of choosing Associate Work Item..., you will choose Associate Change Request... The developer is asked to select a project area where the work item they are looking for resides.
Once the project area is selected, you will see the normal Select Work Items dialog showing all work items from the project area you selected.
And there you have it, a changeset in one CCM associated with a work item in another. Endless possibilities for scaling a development plan.