Make template based project area an "unconfigured one" for master/child inheritance
Hello,
we have a project area that is based on the Scrum template. We also did some changes to the project area like additional work items, new state groups, ....
Now we want to introduce the master/child project area pattern to allow for better control of the process deviations.
Is it possible to make the current project area like an unconfigured one by:
- Removing all attachments
- Reverting/cleaning the xml configuration to be like an unconfigured project are
- What else might be necessary ??!!
PS. It is clear to us that before doing that change all the existing data of the project would need to be migrated to work items/attributes/workflows that are available in the master project area. For that first a (hopefully compatible) superset of the process elements (of current and future master project area) would need to be introduced in the project area.
Thank you for you advice
Greets Marko
we have a project area that is based on the Scrum template. We also did some changes to the project area like additional work items, new state groups, ....
Now we want to introduce the master/child project area pattern to allow for better control of the process deviations.
Is it possible to make the current project area like an unconfigured one by:
- Removing all attachments
- Reverting/cleaning the xml configuration to be like an unconfigured project are
- What else might be necessary ??!!
PS. It is clear to us that before doing that change all the existing data of the project would need to be migrated to work items/attributes/workflows that are available in the master project area. For that first a (hopefully compatible) superset of the process elements (of current and future master project area) would need to be introduced in the project area.
Thank you for you advice
Greets Marko
Accepted answer
One approach you could take:
Create a process template from your existing project area.
Create a new "master" project area from that template.
Modify the existing project area to share the process of the master project area.
Replace the process source XML with a copy of an "unconfigured process" source XML. (You can also get rid of the attachments, but I believe it shouldn't do any harm to just leave them there, and it is handy to leave them there in case you decide to "revert back" to its original state).
Your existing project area should now be fine, since it is inheriting the exact same process you had originally.
(But do some testing to verify ... if something is weird, you can roll back the process source XML).
Now you can create a new V2 master project area, and start removing some of the customizations that you made.
To see if that was "safe", you can then modify the original project area to "share" from the V2 master project area. If that breaks things in ways you cannot fix, you can just shift the "share" pointer back to the V1 master project area.
Create a process template from your existing project area.
Create a new "master" project area from that template.
Modify the existing project area to share the process of the master project area.
Replace the process source XML with a copy of an "unconfigured process" source XML. (You can also get rid of the attachments, but I believe it shouldn't do any harm to just leave them there, and it is handy to leave them there in case you decide to "revert back" to its original state).
Your existing project area should now be fine, since it is inheriting the exact same process you had originally.
(But do some testing to verify ... if something is weird, you can roll back the process source XML).
Now you can create a new V2 master project area, and start removing some of the customizations that you made.
To see if that was "safe", you can then modify the original project area to "share" from the V2 master project area. If that breaks things in ways you cannot fix, you can just shift the "share" pointer back to the V1 master project area.
Comments
sam detweiler
Aug 27 '14, 8:28 a.m.the model is different
one project shares is process configuration (personality), the master
and all others start with NO personality (unconfigured template) and then
clone the sharers personality as their own.
the model I teach is
create your first project from scrum
customize it like you want
extract its process template
make a new project from the process template
share its config
this is the master (anchor project)
create new projects from the unconfigured
consume the master.
never change the master project itself
new changes required.. go back to the original project (since untouched)
and modify
extract the process template
create a new master (anchor project)
change all the children to consume the new master (when they are ready, sometimes the changes are fairly significant and could impact a teams operations)
only the master/parent/anchor projects get created from the real template.
all the children get created from unconfigured.
you can fallback if you have a prior unmodified master..
Marko Tomljenovic
Aug 27 '14, 8:54 a.m.Thanks for the nice description. We now also know that this is the best approach of doing it.
But we weren't that smart with the above mentioned project area.
And unfortunately we can't change it that we need to do the above mentioned migration.
So is it technically possible to revert everything from a project area configuration so that we can "use the process configuration from another project area for this project area" without overwriting anything from the master (anchor) project area?
sam detweiler
Aug 27 '14, 9:00 a.m.I have never been successful at moving a project back to a state where it could correctly start using a master configuration.
in a prior job we had written a custom utilily to move projects between servers, and this utility also allowed us to move/create two new projects under a master/slave configuration.
Marko Tomljenovic
Aug 27 '14, 9:31 a.m.Can you remember what was not working correctly when trying it?
Is this utility publicly available or could I contact the company for it?
sam detweiler
Aug 27 '14, 10:22 a.m.we could never get the different workitems synched properly. (as there were differences between the project and the master template).
there were also some workflow issues, plan configurations, and role problems.
a project newly created as standalone and not yet used would work, by deleting the process config down to the xml statement, and then marking the project as consuming the master. but I never had one of these simple cases in production.
the utility was not available.. I only mentioned it to say that the alternate approach was possible, create a new child project and migrate the data from the old standalone project to the new child (with appropriate conversions) was possible. it does take a lot of work.
Marko Tomljenovic
Aug 28 '14, 1:25 a.m.Thanks a lot for the quick answer although it is not the one I hoped to get ;)