Multiple timelines + delivery constraints problem with RTC 2
I got a problem with setting up the multiple timelines and constraining the delivery to current iteration only.
The timeline tree looks like that: - Main Development (Project Timeline) ---- Sprint 1 ---- Sprint 2 (Current) - Tools Development ---- Sprint 1 (Current) In the Project Area Process Configuration, under the Team Configuration -> Operation Behavior I've set a customization for Source Control -> Deliver (server) operation and added the Require Work Items and Comments precondition, with "Iteration work item is planned for" set to "must be current iteration". I've also have two team areas configured, one for the Main Development timeline and one for the Tools Development timeline. Also I got two categories that are assigned respectively to those two areas. Now what I do is: 1. Create a new work item and assign "Filed Against" to the toolset category. I can see that the team area changes to tools dev team area, which is ok. 2. I assign planned for to toolset sprint 1. I cannot see the arrow behind it which is not ok. But it's still not blocking me... 3. I create a new change set and try to deliver it. Now I get the error in the Team Advisor that states that the work item is not planned for the current iteration. Here's the details: Operation Overview Name: Deliver ID: com.ibm.team.scm.server.deliver This is a team operation, which may be configured in the 'team-configuration' section of the process specification. It may be customized in team area customizations. The operation was run in the context of the Test Team team area. Behavior The preconditions and follow-up actions were configured for the 'default' role in the process specification of the Test project area. You can redefine the preconditions and follow-up actions that are run for this operation by customizing the Test Team team area. Permissions The following actions were permitted for the 'Team Member' role in the process specification defined for the Test project area: modify/stream/deliver/changesets Need Help? If you need assistance, you can email the administrators. What I understand from it is that the change set is assigned to the workspace, which in turn is assigned to a stream that is owned by the project area. The project area's timeline is main development, so effectively the sprint set for the work item doesn't match the current sprint as it's understood from the change set perspective. However, the change set is still assigned to the work item and there is a conflict. Does this imply that the two teams must be working on separate streams? Is there no possibility to share a stream by two teams? Thanks in advance for any help. |
6 answers
Ralph Schoon (63.1k●3●36●46)
| answered May 09 '11, 10:15 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi,
the operational behavior is working with the timeline that the owner of the object is assigned to. For your second Stream you should change the owner to the team which is working against the other timeline. Then the operational behavior should work as you expect it to. Thanks, Ralph I got a problem with setting up the multiple timelines and constraining the delivery to current iteration only. |
|
But unfortunately I got two teams working on the same component of the same stream... Is this situation not supported by RTC?
|
For your case, I would suggest that each team should have its own stream.
And you add an integration stream in which two teams can merge their changes. |
|
Ralph Schoon (63.1k●3●36●46)
| answered May 10 '11, 2:00 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Marcin,
it is a fact that the owner of the stream sets the timeline the stream recognizes and uses for determination of which iteration is current. If two teams work on the same components but have different timelines, how should that work be stabilized ever? The only way to achieve any stable release, I believe, is to have a timeline that coordinates the delivery e.g. the project timeline. The second team could work and there could be an integration process set up that allows bringing in changes made by this team. What I would propose is to have two streams S1 and S2. S1 is owned by the project and S2 by the team 2. S2 could be a duplicate of the one of the project. So they see the same components. Essentially the second team works against S2 and someone integrates the changes at certain points in time. The integrator in Team 2 can point his repository workspace against S1 any time to pick up changes done by the project, integrate their changes and deliver the integrated work back to S1 and S2. Similar the project can have someone do the same when desirable. Thanks, Ralph But unfortunately I got two teams working on the same component of the same stream... Is this situation not supported by RTC? |
|
Thanks for the replies. I think I now better understand what is going on in RTC. The amount of interdependencies between, streams, workspaces, timelines, components, etc. is really confusing at the first time but certainly it is very powerful :) I think I still need to decide about the best way for my team to configure the whole to make development, stabilization and maintenance phases aligned....
|
|
Ralph Schoon (63.1k●3●36●46)
| answered May 10 '11, 10:32 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Marcin,
I agree there is a certain complexity that comes with it. But to automate there needs to be some relaionships, e.g. the stream needs to know the timeline and its owner for operational behavior. Naturally that is the timeline of its owner. Otherwise you would have to configure both information and that would be really error prone, right? Thanks, Ralph Thanks for the replies. I think I now better understand what is going on in RTC. The amount of interdependencies between, streams, workspaces, timelines, components, etc. is really confusing at the first time but certainly it is very powerful :) I think I still need to decide about the best way for my team to configure the whole to make development, stabilization and maintenance phases aligned.... |
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.