Workitem life cycle and streams hierachies what's the link ?
![]()
Hello,
(disclaimer rtc newbie and wastly confused at this point). Let's consider a project area with 2 streams : a Development Stream (DS) and an Integration Stream (IS). The DS build gets deployed on a Development Environment. The IS build gets deployed on a Integration Environment. The DS is basically a code staging area. Once a feature is "done" meaning it is unit tested and tested in the development environment. It is ready to move the Integration Environment for business testing. When a feature is ready to go the IS I'd like 2 things : On one hand i'd like to deliver the change set form the DS to IS (indeed associated to a working item). On the other hand i'd like that work item state to change from in progress -> resolved (defect workflow) , or in progress to implemented ( User story workflow) Is it a mistake wanting to "synchronize" the two ( change set delivery and workitem status)? How do you synchronize the two ? what's the natural way ? How do you maintain consistency : forgetting to deliver a resolved defect from the DS to the IS or conversely delivering an in progress work item. Sorry if it's little unclear. Thanks for your guidance AK. |
3 answers
![]() Hello, I have a similar question. Is there a way to restrict delivering WIs that are not is a "Closed" state group? This would be a fail safe restriction to ensure that a WI is in the proper closed state group, where an operation behavior is set to not allow associating new change sets to WIs in closed state groups. -chris |
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 05 '12, 12:15 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The reason there is no "built-in" semantics between change-set flow and work item state is that the change-set flow relationships are very flexible, and can be changed at any time.
So suppose you had two different integration streams (for two different products), and perhaps a hot-fix stream. Which of those three stream a given change-set should be delivered to depends on the semantics of the change. So what "state" do you give the work item? And now suppose someone "rolls back" the state of one of the streams to an earlier baseline? Should the states of those work items be automatically changed to some other state? So in 3.0 and earlier, the way that you determine what changes are in (and not in) a given stream is by using the Pending Changes view. Coming up in 4.0 will be a much more powerful way of determining what changes are where, and is available in the "Locate Change Sets" menu action. Cheers, Geoff Hello, |
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 05 '12, 12:24 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
In 4.0, there is a built-in process pre-condition on the deliver operation called "Require work items to match query". You would then select a query that only matched closed work items. I'm not sure what release of RTC first introduced this pre-condition.
Cheers, Geoff I have a similar question. Is there a way to restrict delivering WIs that are not is a "Closed" state group? This would be a fail safe restriction to ensure that a WI is in the proper closed state group, where an operation behavior is set to not allow associating new change sets to WIs in closed state groups. -chris |
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.