It's all about the answers!

Ask a question

Migrating projects to new templates


Harry Koehnemann (30125238) | asked Aug 05 '10, 12:05 a.m.
Are there experience or best practices migrating project areas when templates change. The scenario is several we will have several projects created from a standard template. We expect the standard template to evolve and want to migrate those projects, potentially many, to the new versions. After reading jazz.net articles and wiki pages the options seem to be 1) XML merge or 2) reapply the changes to all existing projects. Both look potentially error-prone and painful. We understand there is no easy solution.

What have other's tried to mitigate the migration problem? For example, if we lock projects out of local changes (including permissions, actions), can we cut/paste the XML templates or make the merge easier? If we allow say, permission changes, does the XML merging become dramatically more difficult? Action changes? Is there a model for the XML project area structure that would help us understand it better for migration?

For what it's worth, other products (CQ) seem to have a better understanding of evolving corporate practices and development vs. production template/schema changes and it is discouraging RTC has this limitation.

Thanks in advance for any thoughts on the subject.

6 answers



permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 05 '10, 8:01 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Support for this kind of thing is coming in RTC-3.0.
In particular, in RTC-3.0, you can declare that a project area is the
"master" of another project area. Then when you make changes to the
master project area, those changes are reflected in all the child
project areas.

Cheers,
Geoff

On 8/5/2010 12:07 AM, harryk wrote:
Are there experience or best practices migrating project areas when
templates change. The scenario is several we will have several
projects created from a standard template. We expect the standard
template to evolve and want to migrate those projects, potentially
many, to the new versions. After reading jazz.net articles and wiki
pages the options seem to be 1) XML merge or 2) reapply the changes
to all existing projects. Both look potentially error-prone and
painful. We understand there is no easy solution.

What have other's tried to mitigate the migration problem? For
example, if we lock projects out of local changes (including
permissions, actions), can we cut/paste the XML templates or make the
merge easier? If we allow say, permission changes, does the XML
merging become dramatically more difficult? Action changes? Is
there a model for the XML project area structure that would help us
understand it better for migration?

For what it's worth, other products (CQ) seem to have a better
understanding of evolving corporate practices and development vs.
production template/schema changes and it is discouraging RTC has
this limitation.

Thanks in advance for any thoughts on the subject.

permanent link
Walter Mansur (63613017) | answered Aug 06 '10, 9:55 a.m.
Hi,

I don't know if this is exactly what you want, but we have done something similar here.

We have taken projects that were created using the Eclipse Way form of Agile and migrated them over to a project that is based on the Scrum form of Agile. The "Process Templates" for both of these are very different, as one would expect. Does this sound like what you are trying to do?

Our experience, so far has been a good one with the projects that we did that to. There was some "cleanup" to do as would be expected. But overall we are happy with what we got from RTC.

I know Geoff is going to jump in on this and say that this is "Risky Business", to say the least. I hope he does so and explains why. I do have to admit that this type of subject has come up in this forum before and the recommendation has always been to create new projects with the new process instead of migrating current projects over. I even spoke in person to Kuewai (I hope I spelled that right) after a great presentation he gave at IBM Innovate 2010 and he said the same thing - "Don't do it, if you can avoid it". The bottom line is, even though it is possible to do this, it is not something that IBM Rational recommends doing and they don't support it.

I am happy to see that RTC v3.0 will support this sort of migration better. This new version of RTC is due out in October of this year. You may want to wait until then before trying anything.

Let me know if what we did is what you are thinking of doing and I can followup with you on it. It involved deleting an existing Process Configuration XML file for a project and replacing it with a new one. It was relatively simple. Again, don't move forward with this just on my experience. For the record, we tried it out on "test" projects first.

By the way, I am a longtime user of ClearCase and ClearQuest (UCM) and I loved those products. However, as you start using RTC more and more, you will start saying "Clearcase? ClearQuest? That was before the "Enlightenment" that RTC brought".

- Walter

Are there experience or best practices migrating project areas when templates change. The scenario is several we will have several projects created from a standard template. We expect the standard template to evolve and want to migrate those projects, potentially many, to the new versions. After reading jazz.net articles and wiki pages the options seem to be 1) XML merge or 2) reapply the changes to all existing projects. Both look potentially error-prone and painful. We understand there is no easy solution.

What have other's tried to mitigate the migration problem? For example, if we lock projects out of local changes (including permissions, actions), can we cut/paste the XML templates or make the merge easier? If we allow say, permission changes, does the XML merging become dramatically more difficult? Action changes? Is there a model for the XML project area structure that would help us understand it better for migration?

For what it's worth, other products (CQ) seem to have a better understanding of evolving corporate practices and development vs. production template/schema changes and it is discouraging RTC has this limitation.

Thanks in advance for any thoughts on the subject.

permanent link
Harry Koehnemann (30125238) | answered Aug 06 '10, 1:25 p.m.
Many thanks for the replies Geoff and Walter. Walter, that is similar to what we want to do. It sounds like you did not merge any XML, correct? Only copy/paste. Did you have any existing work items from the Eclipse Way projects? And if so, wasn't there a problem with the lost work items types, enumerations, etc? Or is the Scrum template a pure superset of Eclipse Way?

And I agree, wating a few months for 3.0 is the way to go.

Thanks again for the response.

permanent link
Martha (Ruby) Andrews (3.0k44251) | answered Aug 06 '10, 3:28 p.m.
JAZZ DEVELOPER
Hello Harry,

The information Geoff and Walter gave is correct. I will add a little more, based on my experiences merging process specifications and developing the support for process sharing that Geoff mentioned.

First, some notes about the "master" project area approach that Rational Team Concert 3.0 supports. Geoff explained it well; project areas that consume a process from another project area will automatically reflect the changes to the project that is providing the process. This makes updating easier because only one project area needs to change. If you want to experiment with the feature to see if it meets your needs, I encourage you to download RTC M8 when it becomes available.

There are issues to be aware of when making major changes to the process of any project area. This is true whether you make major changes to a project area that shares its process in RTC 3.0 or whether you merge or edit XML in any version of RTC. The foremost issue is that it is possible to change the project area in a way that will cause problems with existing data. A secondary issue is that the project area editor will not necessarily highlight the fact that you have created XML that will not work correctly. For example, it will highlight syntax errors, but does not report references to elements that do not exist.

The basic approach for major changes is to determine what changes you want to make, run queries for data that woud be affected adversely, change the data so it will continue to work with the new changes, apply the changes and test, test, test. (It goes without saying that you would want to do this in a "sandbox" first before rolling out the changes across an organization.)

Now, some details about updating project areas in RTC 2.0.0.2.

Merging the XML is tricky. I second Kai's statement from Innovate 2010, "Don't do it if you can avoid it". I would also add "Try really hard to avoid it." :>

From my experience, merging in general can be tough because the elements in the XML can get re-ordered when the process is configured. A simple text merge will not work except in the most trivial cases. Adding a role, for instance, is relatively easy.

Merging configuration data can be very trick because different configuration data elements can refer to each other. You must make sure you get all of the "pieces" merged correctly or you may introduce subtle bugs that you do not discover until you try to use the project area. For instance, work item editor might be misconfigured or might not even exist if a merge to add a new work item type is not done correctly.

Preventing customization of the process can simplify the problem because you are able to "stomp" the new version of the specification into project areas without losing customizations. However, you may also need to add process attachments to each project area if your changes reference new attachments.

A reference to the XML syntax for project area specification is here: https://jazz.net/wiki/bin/view/Main/ProcessSpecificationSyntax.

In Rational Team Concert 2.0.0.2, it is possible to update project areas with the new features defined in the 2.0.0.2 process templates. I think this may be what you mean as option 2 in your original post. It is possible to run the updater on several project areas at once, as long as they are in the same repository.

RTC ships with updaters for the process templates shipped with the product. So, if this form of update will work for you if you are using one of the "predefined" templates. But, the updater is *not* for changing the underlying template used by a project area; it merely adds new features for the template used to create the project area. (That is, you cannot use it to move from Eclipse Way to Scrum). Also, it does not add arbitrary changes; the features it will add are pre-defined. (You can extend the updaters with changes if you want to, but this involves writing Java code to do the updates).


Martha
Jazz Developer, Process Team
Many thanks for the replies Geoff and Walter. Walter, that is similar to what we want to do. It sounds like you did not merge any XML, correct? Only copy/paste. Did you have any existing work items from the Eclipse Way projects? And if so, wasn't there a problem with the lost work items types, enumerations, etc? Or is the Scrum template a pure superset of Eclipse Way?

And I agree, wating a few months for 3.0 is the way to go.

Thanks again for the response.

permanent link
Walter Mansur (63613017) | answered Aug 06 '10, 5:39 p.m.
Hi,

Late Friday afternoon response:

I did not merge the Process template files. I deleted the existing one and replaced it completely. There was some "clean up" regarding existing Work Items, but I was pleasantly surprised that almost everything mapped very well. The "clean up" activity was actually very painless. The projects we did this to were not very big. So, that may have been helpful in my particular case.

Having said that and actually gone thru it (and lived to tell about it), I would still recommend waiting for RTC v3.0, since it is so close.

Geoff and Martha are the real gurus for this product. I have been using it for almost a year now. It has been here at my company for 2 years (CareMedic Systems was an early adopter of RTC). I am just reporting on what I actually have done.

I can't say it enough - RTC really is impressive. I have many developers here who would say the same thing. To me, this is another great feature of RTC. The ability to switch processes "on the fly", however it is done, is just amazing and really nice. You should check out what you can do with builds in RTC. For example, I have switched build definitions from one server to another, and RTC did not skip a beat.

- Walter

Hello Harry,

The information Geoff and Walter gave is correct. I will add a little more, based on my experiences merging process specifications and developing the support for process sharing that Geoff mentioned.

First, some notes about the "master" project area approach that Rational Team Concert 3.0 supports. Geoff explained it well; project areas that consume a process from another project area will automatically reflect the changes to the project that is providing the process. This makes updating easier because only one project area needs to change. If you want to experiment with the feature to see if it meets your needs, I encourage you to download RTC M8 when it becomes available.

There are issues to be aware of when making major changes to the process of any project area. This is true whether you make major changes to a project area that shares its process in RTC 3.0 or whether you merge or edit XML in any version of RTC. The foremost issue is that it is possible to change the project area in a way that will cause problems with existing data. A secondary issue is that the project area editor will not necessarily highlight the fact that you have created XML that will not work correctly. For example, it will highlight syntax errors, but does not report references to elements that do not exist.

The basic approach for major changes is to determine what changes you want to make, run queries for data that woud be affected adversely, change the data so it will continue to work with the new changes, apply the changes and test, test, test. (It goes without saying that you would want to do this in a "sandbox" first before rolling out the changes across an organization.)

Now, some details about updating project areas in RTC 2.0.0.2.

Merging the XML is tricky. I second Kai's statement from Innovate 2010, "Don't do it if you can avoid it". I would also add "Try really hard to avoid it." :>

From my experience, merging in general can be tough because the elements in the XML can get re-ordered when the process is configured. A simple text merge will not work except in the most trivial cases. Adding a role, for instance, is relatively easy.

Merging configuration data can be very trick because different configuration data elements can refer to each other. You must make sure you get all of the "pieces" merged correctly or you may introduce subtle bugs that you do not discover until you try to use the project area. For instance, work item editor might be misconfigured or might not even exist if a merge to add a new work item type is not done correctly.

Preventing customization of the process can simplify the problem because you are able to "stomp" the new version of the specification into project areas without losing customizations. However, you may also need to add process attachments to each project area if your changes reference new attachments.

A reference to the XML syntax for project area specification is here: https://jazz.net/wiki/bin/view/Main/ProcessSpecificationSyntax.

In Rational Team Concert 2.0.0.2, it is possible to update project areas with the new features defined in the 2.0.0.2 process templates. I think this may be what you mean as option 2 in your original post. It is possible to run the updater on several project areas at once, as long as they are in the same repository.

RTC ships with updaters for the process templates shipped with the product. So, if this form of update will work for you if you are using one of the "predefined" templates. But, the updater is *not* for changing the underlying template used by a project area; it merely adds new features for the template used to create the project area. (That is, you cannot use it to move from Eclipse Way to Scrum). Also, it does not add arbitrary changes; the features it will add are pre-defined. (You can extend the updaters with changes if you want to, but this involves writing Java code to do the updates).


Martha
Jazz Developer, Process Team
Many thanks for the replies Geoff and Walter. Walter, that is similar to what we want to do. It sounds like you did not merge any XML, correct? Only copy/paste. Did you have any existing work items from the Eclipse Way projects? And if so, wasn't there a problem with the lost work items types, enumerations, etc? Or is the Scrum template a pure superset of Eclipse Way?

And I agree, wating a few months for 3.0 is the way to go.

Thanks again for the response.

permanent link
Jim Wade (111) | answered Aug 20 '10, 4:43 p.m.
I would be interested in finding out more about the "cleanup" that was necessary after replacing the template to move from Eclipseway to Scrum.


Hi,

Late Friday afternoon response:

I did not merge the Process template files. I deleted the existing one and replaced it completely. There was some "clean up" regarding existing Work Items, but I was pleasantly surprised that almost everything mapped very well. The "clean up" activity was actually very painless. The projects we did this to were not very big. So, that may have been helpful in my particular case.

Having said that and actually gone thru it (and lived to tell about it), I would still recommend waiting for RTC v3.0, since it is so close.

Geoff and Martha are the real gurus for this product. I have been using it for almost a year now. It has been here at my company for 2 years (CareMedic Systems was an early adopter of RTC). I am just reporting on what I actually have done.

I can't say it enough - RTC really is impressive. I have many developers here who would say the same thing. To me, this is another great feature of RTC. The ability to switch processes "on the fly", however it is done, is just amazing and really nice. You should check out what you can do with builds in RTC. For example, I have switched build definitions from one server to another, and RTC did not skip a beat.

- Walter

Hello Harry,

The information Geoff and Walter gave is correct. I will add a little more, based on my experiences merging process specifications and developing the support for process sharing that Geoff mentioned.

First, some notes about the "master" project area approach that Rational Team Concert 3.0 supports. Geoff explained it well; project areas that consume a process from another project area will automatically reflect the changes to the project that is providing the process. This makes updating easier because only one project area needs to change. If you want to experiment with the feature to see if it meets your needs, I encourage you to download RTC M8 when it becomes available.

There are issues to be aware of when making major changes to the process of any project area. This is true whether you make major changes to a project area that shares its process in RTC 3.0 or whether you merge or edit XML in any version of RTC. The foremost issue is that it is possible to change the project area in a way that will cause problems with existing data. A secondary issue is that the project area editor will not necessarily highlight the fact that you have created XML that will not work correctly. For example, it will highlight syntax errors, but does not report references to elements that do not exist.

The basic approach for major changes is to determine what changes you want to make, run queries for data that woud be affected adversely, change the data so it will continue to work with the new changes, apply the changes and test, test, test. (It goes without saying that you would want to do this in a "sandbox" first before rolling out the changes across an organization.)

Now, some details about updating project areas in RTC 2.0.0.2.

Merging the XML is tricky. I second Kai's statement from Innovate 2010, "Don't do it if you can avoid it". I would also add "Try really hard to avoid it." :>

From my experience, merging in general can be tough because the elements in the XML can get re-ordered when the process is configured. A simple text merge will not work except in the most trivial cases. Adding a role, for instance, is relatively easy.

Merging configuration data can be very trick because different configuration data elements can refer to each other. You must make sure you get all of the "pieces" merged correctly or you may introduce subtle bugs that you do not discover until you try to use the project area. For instance, work item editor might be misconfigured or might not even exist if a merge to add a new work item type is not done correctly.

Preventing customization of the process can simplify the problem because you are able to "stomp" the new version of the specification into project areas without losing customizations. However, you may also need to add process attachments to each project area if your changes reference new attachments.

A reference to the XML syntax for project area specification is here: https://jazz.net/wiki/bin/view/Main/ProcessSpecificationSyntax.

In Rational Team Concert 2.0.0.2, it is possible to update project areas with the new features defined in the 2.0.0.2 process templates. I think this may be what you mean as option 2 in your original post. It is possible to run the updater on several project areas at once, as long as they are in the same repository.

RTC ships with updaters for the process templates shipped with the product. So, if this form of update will work for you if you are using one of the "predefined" templates. But, the updater is *not* for changing the underlying template used by a project area; it merely adds new features for the template used to create the project area. (That is, you cannot use it to move from Eclipse Way to Scrum). Also, it does not add arbitrary changes; the features it will add are pre-defined. (You can extend the updaters with changes if you want to, but this involves writing Java code to do the updates).


Martha
Jazz Developer, Process Team
Many thanks for the replies Geoff and Walter. Walter, that is similar to what we want to do. It sounds like you did not merge any XML, correct? Only copy/paste. Did you have any existing work items from the Eclipse Way projects? And if so, wasn't there a problem with the lost work items types, enumerations, etc? Or is the Scrum template a pure superset of Eclipse Way?

And I agree, wating a few months for 3.0 is the way to go.

Thanks again for the response.

Your answer


Register or to post 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.