Best practice to update multiple project areas in RTC
We have been looking at two ways to update multiple project areas with standard changes. We looked at the process sharing and also using a template to update all our RTC project areas.
In our concept of process sharing their would be a master project area and all other project areas would share/inherit from this master.
In our concept of using a template we would have a project area setup to only manage template changes and then export the new template and change the other project areas to this new template.
Which is the best practice and why?
Thanks in advance for your help!
|
Accepted answer
Ralph Schoon (63.5k●3●36●46)
| answered Jul 02 '21, 11:06 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jul 02 '21, 11:08 a.m.
There is no best, there are only tradeoffs.
Big customers with multiple project areas usually use procerss sharing blocking local process changes and -overrides. This allows a standard process and allows to further develop it and to switch to it when desired.
You can not deploy a template on an existing project area. The only supported way to confinue developing the process would be to change it manually in each project area. I would stronglx advise not to try to paste a process XML over another process.xml.
But if you have agile teams that want to develop their own process and standadizing and conformity is not a factor, this it is a valid model to have multiple processes. You can also try multiple standard processes with process sharing.
Brad Morse selected this answer as the correct answer
Comments When using process sharing with a master project area is it possible to change the blocking of local process changes once the shared project areas are created, or are the settings locked in once a project area shares the process?
Also, once a project area is setup as standalone can it later be configured to share a process area from a master project area? I see this option but wondering if that will cause issues and not a best practice.
Geoffrey Clemm
commented Jul 02 '21, 3:31 p.m.
| edited Jul 02 '21, 3:32 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
A child project area can always override the process from the parent project area, but note that this happens in "chunks", corresponding to sub-trees in the process definition XML source. Before you override a given chunk of process, you will see that this chunk is marked as "(unconfigured)" in the Process Configuration. When you click on "Customize this Configuration Data", you are copying that chunk of process from the parent process definition to the child definition (where you can now customize it). But note that the child definition of that chunk completely overrides the process definition of that chunk, so that future changes to that chunk in the parent process are invisible to the child. In order to switch back to having that chunk of process be inherited from the parent, you would delete the XML node in the process source for that child. But if you do this, any artifacts in the child project area that were based on customizations that were made in that deleted child chunk no longer have those customized definitions available, which could make those artifacts unusable by end users.
As Geoff describes, you can revert overwriting the process you share by deleting the overwriting XML node(s). But if you do that, you will likely loos customization information. If you decide to have different processes and process templates in the beginning, it is very hard to go back to process sharing. See:
https://jazz.net/wiki/bin/view/Deployment/SetupProjects has a lot of related links as well.
If I follow these steps do you think this works well in RTC?
1. export project area template from production project area
2. import the production template into sandbox
3. create new project area in sandbox using imported template
4. change new sandbox project area
5. copy Process Configuration Source from sandbox to production to promote changes
Ralph Schoon
commented Jul 08 '21, 5:18 p.m.
| edited Jul 08 '21, 5:21 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I think I have tried to nicely suggest process sharing. There are articles how that works.
If you do not want to use that, the procedure is to create a process template and to create a project area from that. Then maintain the process in each project area.
I do not know what the purpose of the steps above is.
Step 5 is for me something you can do but is not supported, and if you do not know what you are doing can screw up your project area. You can likely fix this, if you know what you are doing, but I am reasonably sure that that is not documented and you are way out of the realm support would help to cover. You do not just copy process XML over an existing project areas process. This can, worst case, completely destroy a project areas process.
Hi Ralph,
Thanks again for commenting.
I'm trying to figure out how manage project areas that are not sharing processes and make the change in a sandbox environment and promote same changes to production.
The first 4 steps above are to create a copy of production in the sandbox and then change that sandbox copy. Step 5 should then be copying a changed process created from production back to production.
Please help me understand if I copy the entire Process Configuration Source from this changed production copy in the sandbox to replace the entire PCS in production how that would cause issues?
This seems to be the only way to promote an unshared process from the sandbox to production. This also allows testing in the sandbox first. Which is why I hope this can be a viable process.
Brad, the only supported way of maintaining processes of project areas that are not share is: Use the UI and manually perform the desired change.
I have no experience with just copying the XML over, other than using a previous after an undesirable change. As long as you can make sure that the process of the project areas is not changed this might be an option, but I am not entitled to provide a go /no go. I would probably check the unconfigured process and what process sharing manages to make sure there is no XML that should not be copied.
Mind the database managed enumerations are not stored in the XML. Do not use them if you rely on copying..
Geoffrey Clemm
commented Jul 09 '21, 5:16 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Brad: What is the reason you are considering the XML process source approach instead of the standard master/child process sharing? Earlier, you asked about being able to modify parts of the child process ... but that doesn't work with the XML process source approach either ... when you copied over the XML process source, it would wipe out any of the changes you made in the child process. Hi Geoffrey,
We looked at the Master-child process sharing and thought it to be too restrictive. If setup this way and all the sharing project areas did not want the same changes this approach does would not work for us. However, the Process Configuration Source XML can be used to make the changes in the sandbox and move them into a particular project area in in production (following the process steps above). That is one of the main reasons - we need to make the changes in the sandbox and test the changes prior to promoting to production. Also, I'm not sure we can do this with the process sharing approach.
Geoffrey Clemm
commented Jul 21 '21, 4:30 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Replace step 5 with "create process template from sandbox, and create new master project area in production from that process template", so you can get rid of any operation that directly involves Process Configuration Source XML. For project areas that have not customized the Process Configuration, they can just update their master process area to be the new master project area. For project area that have customized their Process Configuration, they have two choices: (a) figure out what changes were made in the new master project area and manually make those same changes in their project area, or (b) update their master process area to be the new master project area, remove any of their customizations, and then redo their customizations against the process they are now inheriting from the new master project area.
showing 5 of 10
show 5 more comments
|
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.