Scaling a Plan
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.