Experts in DevOps and UrbanCode

Scaling an SCM

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.

Copyright © PacGenesis, Inc. 2016. All rights reserved.