What about Jazz Project Move capability?
Daniel Toczala (882●1●15●14)
| asked Jun 03 '12, 2:49 p.m.
FORUM MODERATOR / JAZZ DEVELOPER edited Jun 14 '12, 4:11 p.m. by Rob Retchless (311●2●5) This is not really a question - it is a collection of use cases and observations that were captured during the VoiCE sessions held on June 3, 2012 at Innovate 2012. I hope that we can have a running conversation on the use cases and concerns that are critical for any useful implementation of a Project Move capability. If you have other use cases for Project Move, or other observations, please comment on this forum thread and share your ideas. Observations
Potential Use Cases
|
5 answers
A very good and valid point. The question might be allowed if this will support an enterprise scope?
But first I would like to point out that - from my point of view - two things have been put together, which should be handled separately. On one hand the project move and on the other hand bulk operations on work items. The last one is something which is needed even without the ability of project move. But getting back to the project move. My initial question would be: "What are the needs of an Enterprise dimension?" Is moving data from one physical installation to another the goal? What happens if a project area is moved from one environment to another? In the first place all artifacts will get new work item ID's. Based on this initial fact all information that is to some extend tight to the ID information has to be changed. Every place where for example the string "Task 101298" has been used it has to be replaced by the new ID and by this a new URL has to be inserted. In any description, discussion, history trail or other possible location. Lets assume that it was possible to clean all this references up in the sending and the receiving environment. Be aware that this has to be done on both sides. Now we have all the references related to our exmaple wok item "Task 101298". Which have to be corrected now as well. So not only the work item references have to be correct the references in all the impacted work items has to be corrected a well. Now assuming that we have at the end cross server relationships. There seams a lot of places where something can get wrong. After reflecting about this with our engineering team we came up on the last years Innovate with the totally different proposal. The main requirements to such a solution were very simple.
After having now reflected on all this the assumption would be that a simple project move will never support the complex scenarios which will happen within a enterprise solution which has to support a world wide distributed organization. Taking the cloud cluster into consideration aspects like
I hope it was possible for me to express the view we have and contribute in some way to your post. |
another use case, we have multiple repositories, is to co-locate teams of projects on the same repositoy so that they can effectively share data (links between workitems), which can't be done on the current product function.
Comments
Markus Schille
commented Aug 16 '12, 4:44 a.m.
I am absolutely with you on this. Therefore my proposal to have a cluster that is using the same name space which would be a prerequisite combined with project move. A little bit like a combination of distributed infrastructure with the way virtual guest can be moved around on their physical hosts. Here the virtual guest would be the project area where the physical host is part of the distributes cluster. ok, now I get it.. but.. how does this help me for the current situation? for new installations I could define the data model differently to add some virtual namespace label. I suppose you define a new url model with the namespace id, and all those without it get special handling (redirect). |
Rather than trying to solve all problems in the world I'd suggest to look at which set of features would make a minimal viable solution.
We would be happy to see a project move that would
|
I find the scenarios you have described to be valid ones.
I could add another one, but it probably will fall under one of the heading you already listed.
Security problems, or security update to a project could compel you to move a project out of an existing server to a different one, of course preserving the data and history.
It probably could be just a variation on item #1 of your list.
Question is, is anything moving on this subject, if it comes up regularly ? Any update we could find anywhere ?
Regards
Comments Hi Bruno, I think there is nothing consumable as of now.
Bruno Di Giandomenico
commented Oct 30 '13, 6:57 a.m.
Thanks for the prompt answer.
My suggestion would be to pragmatically start with something, just to gauge the difficulties. I am aware of the things which you would have to consider, links, users, roles, permissions, and I am aware that there is no easy answer.
Anders' requirements would be a start, even if losing history is quite bad. But it would be a start.
|
Ralph Schoon (63.4k●3●36●46)
| answered Jun 27 '13, 8:55 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
This comes up on a regular basis and I can see these major reasons for it:
There might be more scenarios I didn't recognize. Some with slightly different background e.g. template projects for seeding new projects that I would not see in the project move domain.
Comments
Markus Schille
commented Oct 30 '13, 11:23 a.m.
Do you know what the actual status on this discussion/investigation within IBM is?
the last status I saw was 'on the backlog', not scheduled for any release.
Markus Schille
commented Oct 30 '13, 12:11 p.m.
Sound very simple. But there is more behind the scene ongoing. If it would be that simple we have not discussed the issue for several years.
sam detweiler
commented Oct 30 '13, 1:50 p.m.
if you use the same JTS, then you have one user base across all CCMs, one security model, ...
Markus Schille
commented Oct 31 '13, 2:35 a.m.
I am fully in line with what you describe. One other specialty is that we have found out over the years that the architecture and the way things have been implemented in RTC, RQM, RRC and JTS have not been aligned at all. In some case even the name is used and not the UUID, which brings other problems on the table. Search functionalists in one service are different implemented and by this bring different results instead of having one search routine reused. There are many of those examples.
Sam, with respect to the work item ID's, you can set the number, provided it is not already taken, in the API.
I forwarded the question to a developer, who hopefully can point the right persons to it.
sam detweiler
commented Oct 31 '13, 8:20 a.m.
Ralph, re setting the ID.. in practice this rarely is possible as all the servers start with the same base value.
Georg Kellner
commented Oct 31 '13, 11:16 a.m.
Ralph, of course you can't know everything at the beginning, but I think IBM Rational isn't the first company developing the first SCM tool or state machine in the world.
showing 5 of 9
show 4 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.
Comments
On the engagement I ended last month, we had to do a project move from one RTC 3.0.1 to another 4.0.4. we wrote two utilities to make this possible,
1. move all the project config stuff
timelines & iterations, users, teams (& roles), categories, plans, source, & builds
x. use the builtin workitem export/import to move the data and fix workitem differences (going from non shared to shared process template and different workitem types)
2. copy & fixup all the links, comments, descriptions, attachments, approvals.
we did not resolve history, or fixup source changesets to workitem links, or reports/user queries.
we also had not completed migration of any custom plan views (ran out of time and there weren't many on the source system)
we combined 3 source projects into a single resultant project.
I believe they intended to use this process to handle onboarding teams from other tools.
build project in sandbox, migrate data, customize/resolve issues, get signoff
then replicate project to production system.
We did this in test a few times to validate that it worked.