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.
Accepted 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?
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.
If I follow these steps do you think this works well in RTC?
I think I have tried to nicely suggest process sharing. There are articles how that works.
Hi Ralph,
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.
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,
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.