Best Practices on Process Template Change Management
![]()
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 |
5 answers
![]()
Geoffrey Clemm (30.1k●3●30●35)
| 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.
|
![]()
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 |
![]()
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).
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?)? |
![]()
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
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
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.
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