Managing Rational Team Concert work item changes with process sharing
Introduction
This article will help users toward implementing new work item types (process definitions) or major customization or changes to existing work item types (process definitions) into an active environment of IBM Rational Team Concert (RTC) with minimum risks as well as minimum downtime or disruptions.
Benefits
- Minimal time required to implement new work items into production.
- What is tested is exactly what is implemented into production, with no additional manual steps required.
- Clean back-out with significantly reduced time required to roll-back to the previous implementation.
- Centralize the processes, thereby maintain integrity of such (corporate, department or program) process, reduced overheads of maintenance. Additionally, such process standardizations enforce common practices, thereby improving reuse amongst practitioners regardless of staff movements/reassignments within the organization.
- Effective and efficient way to enforce (corporate, department or program) process standards.
Special Notes
- Advanced knowledge of RTC, and especially RTC process configurations are pre-requisites for this article. As such, it avoids any screenshots of steps that are regularly exercised during normal RTC administration activities.
- Unless otherwise stated, the term ‘project’ means an RTC ‘project area’.
- Scope of this article is limited to sharing of process configuration for work item types only. It is not intended to cover sharing any other configurations (eg. Planning, Timelines, Iterations etc).
- One specific issue identified is outlined in section ‘Known Issue and Resolution’ which should also be reviewed. Presently, the resolution steps cannot be performed using the Web UI, thus this article covers only the Eclipse client.
Needs Summary
Many projects or programs are increasingly using RTC for work item management, including Change Requests, Risks, Actions, Issues, Defects etc. The increased institutionalization of such practices often lead to a need to add additional work item types and/or further enhancements to existing work item process definitions.
Often these changes need to be applied while a project team is actively using the RTC environment with potentially 100’s or 1000’s of work items having already been entered using the previous process template configuration/s.
Technological Constraints
Presently, RTC does not provide a simple means of merging (combining) changes of process definitions between two project areas. Thus, a typical practice to effect enhancements are to make changes to a non-live, eg. a test project area first. Once testing is complete, the steps are repeated to effect the changes onto the live, production project and retest. This is risk-prone due to the below considerations:
Often these changes need to be applied while a project team is actively using the RTC environment with potentially 100’s or 1000’s of work items having already been entered using the previous process template configuration/s.
- The only way of merging the changes from the non-live project into the live project is to manually repeat the steps to effect these changes into the live project area. Being a manually intensive exercise, this increases the likelihood for human errors.
- What was tested (using the development project) is not necessarily what is implemented into live project (due to the manual repeat of the changes).
- Any rework after implementation is difficult to manage due to the potential for such changes to cause immediate impact to existing users and/or work items. All such actions being manual increases the likelihood for human errors.
- Back-out of changes are extremely difficult to manage as each change/update activity have to be individually tracked and reversed accordingly. Again, all such actions – being manual, increases the likelihood for human errors.
Resolution Summary
This article details the steps on how to manage such work item customizations and process changes with significantly reduced risk to the existing use of RTC for work items. The change can be implemented without any interruptions to end users; however, it is preferable to have a short outage window to promote the changes and validate.
No RTC services need to be shut down or restarted.
The technical strategy has been feasible since RTC V3.0.1 and is based on the ‘Process Sharing’ feature provided in the recent versions of RTC.
Below is a high-level visual representation of the strategy:
Refer more detailed screenshots below, covering each of the major Steps:
a) Prepare existing project areas to share processes from a Master Process (Template) project:
b) Setup the configuration to commence development (of new work item types or major changes to existing work item process definitions):
c) Go live with the last confirmed changes, prepare for the next enhancement iteration of work item type process definitions:
Step by Step
1) Ensure current production project area remains unaltered. Assume there are three projects (per previous diagram, these are ‘Project 1’; ‘Project 2’ and ‘Project 3’) which will be collectively referred to as “LiveProjects” in the remainder of this document. Assuming all three projects have exactly the same process configurations, create a fresh template from one of these project areas.
2) Using the template created at step 1, create a new project area with a meaningful name and version, eg. “Master 1”. The intent here is to establish the current process configurations for the ‘LiveProjects’ but with the new project area ‘Master 1″ as the provider.
3) Open the process configuration pages. In the Eclipse UI, right click the project “Master 1”, then click Open. Open the ‘Process Configuration’ tab.
4) Expand section ‘Project Configuration’, then expand ‘Configuration Data’ and finally, expand ‘Work Items’. For each of the work item process configurable items (eg. ‘Types and Attributes’, Enumerations’, etc), tick the check box “Final (ignore customization of this data in child project areas)”. The check box for ‘Predefined Queries’ may be left unchecked.
5) Complete this step for each of the ‘Configuration data” > ‘Work Items. The check box for ‘Predefined Queries’ may be left unchecked.
6) Open the Overview tab of the project configuration, and check the box “Allow other project areas to use this project area’s process”.
Click Yes to continue.
7) Save to commit the configuration setting changes. The save may fail due to one of the known issues, in which case, refer section ‘Known Issue and Resolution’.
8) Create a fresh test project (eg. Test) from the ‘Unconfigured Process’ template, to persist as the testing project area for all iterations of the process configuration changes in the future.
9) Open the test project configuration. In the Eclipse UI, right click the project “Test”, then click Open.
10) Open the “Overview’ tab. Click to select the radio button for “Use the process from another project area for this project area”. Click Change button, the project name “Master 1” will be displayed (amongst any other project area which may have been configured to share its process). Select that project and click OK to continue.
11) Save to commit the configuration setting changes.
12) The setup is now complete and you are ready to proceed with the enhancement work.
13) Its best to identify a set of sample work items which may be used in step 19. Ideally the sample work items should have attachments, hyperlinks, relationships with other work items (Parent/Child/Related) etc.
Follow the steps below to commence the development, testing, rework and retest etc:
14) Make all changes to the master “Master 1” .
15) Test using “Test”.
16) For any rework, go back to the master “Master 1” and make changes to it. Retest using “Test”.
Once testing is complete, follow the steps below to implement:
17) Open the configuration page for the production project “LiveProjects”.
18) On the Overview tab, follow the action similar to those outlined earlier in step 10 and 11. Thus, mark the live projects (LiveProjects) to borrow its process from “Master 1”. Click Save.
1) Conduct some validation testing to ensure existing work items in “LiveProjects” are unaffected. Its not feasible to test all work items, thus a sample identified is step 12 should be used for validation testing. Ideally the sample should contain work items with attachments, hyperlinks, relationships with other work items (Parent/Child/Related) etc; and these should also be verified.
Conditional Step: Back-out.
20) In the event that the “LiveProjects” need to revert back to the status prior the changes, simply reverse the action taken in step 18. Thus, for the “LiveProjects”, open the overview tab, and select the option shown below:
This will immediately reverse out all of the changes, thus reverting the live projects (LiveProjects) to its previous status.
Note: The screenshot shown above applies only for the very first time that the strategy is used. For subsequent iterations where prior version does exist, set the (Process Sharing) option to that previous version of the master project. In this regard, its important that the previous master project is not archived for at least 7 days to allow the productive project areas (“LiveProjects”) to reach steady-state, ie. with no defects directly related to the updates.
Additional Considerations
- For the next iteration of work item changes, follow the similar flow, ie. create a new master “Master 2” based on the previous master “Master 1”.
- Make the “Test” to borrow its process from “Master 2” (using steps similar to steps 9, 10 and 11 above).
- Use “Master 2” to make further enhancements/developments. Test using “Test”. Rework on “Master 2”, retest using “Test”.
- To implement this next set of enhancements into the live project, update the configuration of “LiveProjects” to borrow its process from “Master 2” (being the revised, new master containing the latest changes).
- If back-out is necessary, simply switch the “LiveProjects” configuration settings to borrow from the previous master “Master 1”.
- Once successful implementation is confirmed, its best to archive “Master 1” after a period of time (eg. after 5 to 7 working days with no issues).
Project Naming Standards:
The article has used simplified names for the master and test project areas as these are essentially examples only, and used to illustrate the strategy in a simple manner. For an actual implementations, a meaningful naming standards should be established and rigorously followed to avoid any confusions, especially with the master project. This is important to ensure correct steps are followed for going forward with the next set of changes and/or to ensure that back-out – if necessary, uses the correct master project.
Known Issue and Resolution:
One specific issue has been identified. This section outlines the issue and its resolution to complete the work item configurations only to be shared by other projects. The resolution step may lead to other possible configuration changes necessary to meet other needs which are outside the scope of this article. The issue may arise when a template may be used as the start-up of the master project. The steps outlined below cannot be performed using the Web UI, thus this article covers only the Eclipse client only.
At the time of saving the master project configuration changes (refer Step 7 earlier), a possible error message is “Project area cannot provide process for others because it configures process for timelines or iterations”; as shown below:
This error is caused by settings in the operation behavior of the ‘Iteration Types’.
To resolve:
21) Navigate to and then expand ‘Team Configuration’. For each iteration defined, expand the iteration types. If any of the definition’s ‘Operation Behavior’ is displayed in bold fonts, it indicates that some configuration definitions exists. Thus in the example below, Iteration Type= ‘Design phase’ has no configurations (non-bold font), whereas, ‘Code phase’; ‘Testing phase’ and ‘Requirements phase’ do (bold font display).
22) For each of the above iteration types with configuration (bold font display), click to open the ‘Operation Behavior’, then locate the precondition criteria specified.
23) Clear the check box ‘ Pre-conditions and follow-up actions are configured for this operation’ (shown below):
24) Repeat for each of the applicable iteration types. In this example, repeat for ‘Code phase’; ‘Testing phase’ and ‘Requirements phase’. Thus, the resulting screen should correspond to the one shown below:
25) Click to Save the configuration. Return to step 7 to complete the save and continue with remaining steps.
26) If the same error message (ie. the problem) persists, follow the below additional steps:
26a) delete all timelines and iteration definitions from the Master project area (using the Overview Tab);
26b) Open the Process Configuration Source tab, scroll down towards the end or use the Find facility for the text (without the double-quotes) ““.
Check if there is the XML code shown below and if so, delete the two lines (marked out in red).
(note: somewhat similar but other code as shown below may also be present; delete the (four) lines outlined in red.)
26c) Restart RTC. Return to step 7 to complete the save and continue with remaining steps.
Note: the timeline and iterations are “not” to be borrowed (ie. cannot be borrowed and should not be borrowed). Each child project area is assumed to define and use its own timelines and iterations.
Strategy Implementation
Sumant Bhattacharya has successfully exercised this strategy in practice for at least three separate iterations in a very large RTC implementation in Australia with 10,000+ work items.
For more information
- Jazz Community – Rational Team Concert
- Process awareness and customizability
- Getting Started with Work Items in Rational Team Concert – article about using work items
- Work Item Customization in Rational Team Concert – article about customizing work items
About the author
Sumant Bhattacharya works in a team of dedicated professionals who deploy and support Rational products for IBM managed projects in Australia and New Zealand.
Copyright © 2012 IBM Corporation