It's all about the answers!

Ask a question

Best Practices on Process Template Change Management


1
1
Vinay Kumar AV (17923437) | asked Aug 22 '12, 5:46 a.m.
Hi

We have a distributed team and with around 3 people playing the role of Project Admins to develop the process template. What are the best practices associated with making changes to the process template? I would want to track each change made to the RTC process template as a task in RTC and associate the template code changes as a change set and version the templates as well using the Jazz SCM. Is there any ready process or documentation available to achieve this process implementation.

We advocate the above as a best practice for teams using RTC. However, I see that it may not be easy to manage the RTC process template changes using RTC. Correct me if I am wrong on this.

Regards
Vinay

Comments
1
Sterling Ferguson-II commented Aug 22 '12, 8:49 a.m.

Hello,

When Rational had the Plan Jam, I wrote of a similar idea. It seems in RTC--a tool build on planning, scm and change management--that you can easily make changes to templates and go live without any audit. I asked for a way in which RTC could use "itself" so that users could create work items to make changes to templates, scm, etc.

I have not seen anything on this. Create an enhancement and post it here and I will subscribe.


1
Vinay Kumar AV commented Aug 22 '12, 10:56 a.m.

Here you go... I have made this an Enhancement....

https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=227997

5 answers



permanent link
Chris Goldthorpe (4287) | answered Aug 22 '12, 12:22 p.m.
JAZZ DEVELOPER
RTC does not currently have a way of associating work items with changes to the process configuration. Thanks, Vinay for opening the enhancement request. There is a way of showing the history of a process specification, in the Eclipse client if you open the project area editor, select the Process Configuration Source tab and right click in the editor area you will see "Show History" as a submenu command.

Comments
sam detweiler commented Aug 22 '12, 5:14 p.m. | edited Aug 22 '12, 5:15 p.m.

thank you.. another thing learned!

and if you double click on one of those history entries, you will get the actual source AFTER that change was applied..

a careful xmldiff will show you WHAT..


sam detweiler commented Aug 22 '12, 5:23 p.m.

AND, if you select any two of the change entries, you can compare them with the eclispe compare tool.. more things learned


Vinay Kumar AV commented Aug 23 '12, 5:51 a.m.

Thanks Chris... I do use this feature to help see who did and what on the process template. But it will be nice if we had this tracked as a change managed effort within RTC. This becomes even necessary when we have parent child project areas where process templates are shared and inherited.

BTW, my enhancement has been marked a duplicate of this WI:

https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=196580


permanent link
Geoffrey Clemm (30.1k23035) | answered Aug 24 '12, 5:16 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Currently the best (really, only :-) way of dealing with this is to export your process template to an RTC sandbox in file system, and then checkin those files.  The main problem (other than it being somewhat cumbersome to execute the sequence of necessary commands) is that process attachments get renamed as part of the "export" process, which means that attempts to merge two streams of development of a process template requires the manual and error-prone step of trying to resolve all the the process attachment name conflicts that result from that unnecessary renaming.  This issue is tracked in work item 174120.   If you are interested in doing parallel development of your process configurations, please feel free to add a comment to https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/111668 to indicate your interest/support.

Comments
Vinay Kumar AV commented Aug 27 '12, 7:51 a.m.

Have updated the WI expressing my interest as well. This is a much needed feature.


permanent link
sam detweiler (12.5k6189201) | answered Aug 24 '12, 9:34 p.m.
Also see workitem https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=214934
which requests fine grained delta function on process configurations

sam

permanent link
Marc Towersap (481711) | answered Feb 14 '13, 12:24 p.m.

I really haven't seen a definitive answer on this.  I am wondering if, when I see 'create a sandbox', this is what you are doing (as I'm doing).
1) create a new RTC install that's in isolation to other RTC (typically, on your own laptop that uses localhost) using 10 user license and derby db
2) create fake users (dev, test, etc.) with appropriate license.
2) If necessary, import template you are going to modify
3) create project area using the desired template as your baseline, and add appropriate dummy users to test (dev, test, etc.)

4) start playing. This could mean creating testing, then abandoning attributes if you try something then need to abort it because you tried one type of attribute, but found it didn’t work like you wanted, but you can’t change the type after you created it (at least I can’t, ‘type’ is greyed out).

5) once you get close to a working template, you export it in your isolated instance (but give it a non-official name/ID since it’s likely this isn’t the final version), then create a new project area that is based on that new instance, add the same users, and test your template.  Consider this your unit test of the template.

6) repeat steps 4 and 5 until you get a good working template that seems ready to roll-out.  Give that semi-final name of *-beta.1  (since you likely aren’t done yet). Then export the template you want to test to a test instance where others can see it. Create another working instance off that beta.1 template, then let others test it.  Each template beta implementation should increment the beta number (beta.1 to beta.2 to etc.)

7) When you finally get done, the final beta looks good, then save/export it as the official template version (drop the beta name).

8) destroy the isolated sandbox instance (so that gets rid of all the abandoned attributes) by uninstalling RTC/JTS and deleting the workareas.

Is this what people are basically doing?

Another question is, for large enterprises, is there a possibility of ID collisions (if my exported template has an attribute ID of defect.newfield.attribute  for my final template, and some other RTC server also has the same defect.newfield.attribute, especially if that other server has a different type (maybe medium string, may be enumeration)?  What happens then if you try to import your template that has the colliding ID?

And a final question, I haven’t seen this (may be I missed it), but is there a way to upgrade a project area with a newer version of the template (assuming existing project areas didn’t modify anything so there’s no risk of colliding ID’s?)? 


permanent link
Daniel Toczala (88211514) | answered Feb 15 '13, 10:04 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
I agree that this is not supported as nicely as we would like, and I strongly support an effort on the work items mentioned in this thread.

For people just looking at how they should enact their current software development processes with jazz, I would strongly encourage you to take a look at the Process Enactment Workshop (https://jazz.net/library/article/1093).  It covers how to use Rational Method Composer to define and update process for Jazz projects.

Your answer


Register or to post your answer.