It's all about the answers!

Ask a question

Working with work items


Christer Palm (5641) | asked Dec 13 '10, 9:54 a.m.
Hello!

We're evaluating RTC 3.0 and I haven't been able to find any references that would help me to understand how to use work items to represent configurations.

There are many things I haven't been able to figure out, but let's start with a simple one:

How do I move all the changes related to a Scrum story from a development stream to an integration stream?

Best Regards,
Christer Palm

14 answers



permanent link
Anthony Kesterton (7.5k7180136) | answered Dec 13 '10, 12:23 p.m.
JAZZ DEVELOPER
Hello!

We're evaluating RTC 3.0 and I haven't been able to find any references that would help me to understand how to use work items to represent configurations.

There are many things I haven't been able to figure out, but let's start with a simple one:

How do I move all the changes related to a Scrum story from a development stream to an integration stream?

Best Regards,
Christer Palm


Hi

The way to move changes (I assume you mean your code changes) from one stream to another is to have the changes loaded in your repository workspace, then switch the flow target of your repository workspace to your integration stream and Deliver to that integration stream. Right button on the repository workspace in your Pending changes view to change the flow target.

You may want to take a baseline (if the changes are in one component) or a snapshot (if your changes are in multiple components) so you have a control point to go back to.

I am not sure I understand what you want to do with the work items and configurations - can you explain?

regards

anthony

permanent link
Christer Palm (5641) | answered Dec 14 '10, 4:26 a.m.

The way to move changes (I assume you mean your code changes) from one stream to another is to have the changes loaded in your repository workspace, then switch the flow target of your repository workspace to your integration stream and Deliver to that integration stream. Right button on the repository workspace in your Pending changes view to change the flow target.


Hi!
The problem is that I cannot see my stories (or any other higher-level work items) in the Pending Changes view, only the work items that have change sets directly associated with them.
To clarify, I'm trying to find the right way to deliver a (potentially very large) controlled set of changes.

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 14 '10, 10:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I do not believe you can do what you are asking.
But I do agree it is a very reasonable thing to want to do, so I have
submitted work item 148142 requesting this functionality.

Note that best practice is to accept those changes into a workspace, so
you can confirm that this is a reasonable configuration, before you
deliver it. Once you have confirmed that the workspace content is
reasonable, you would use the standard "deliver" operation on the
workspace to get those changes into the stream.

So I have phrased the work item in terms of new "accept" functionality,
rather than new "deliver" functionality.

Cheers,
Geoff

On 12/14/2010 4:38 AM, cpalm wrote:
kestertowrote:

The way to move changes (I assume you mean your code changes) from
one stream to another is to have the changes loaded in your
repository workspace, then switch the flow target of your repository
workspace to your integration stream and Deliver to that integration
stream. Right button on the repository workspace in your Pending
changes view to change the flow target.

Hi!
The problem is that I cannot see my stories (or any other higher-level
work items) in the Pending Changes view, only the work items that have
change sets directly associated with them.
To clarify, I'm trying to find the right way to deliver a (potentially
very large) controlled set of changes.

permanent link
Christer Palm (5641) | answered Dec 14 '10, 1:49 p.m.
Note that best practice is to accept those changes into a workspace, so
you can confirm that this is a reasonable configuration, before you
deliver it. Once you have confirmed that the workspace content is
reasonable, you would use the standard "deliver" operation on the
workspace to get those changes into the stream.

So I have phrased the work item in terms of new "accept" functionality,
rather than new "deliver" functionality.

Actually, when I wrote "deliver" I was thinking of delivery in a wider sense, i.e. getting the set of changes from one stream to another. Sorry for the confusion!

I do not believe you can do what you are asking.
But I do agree it is a very reasonable thing to want to do, so I have
submitted work item 148142 requesting this functionality.

OK, thanks!

Unfortunately, I believe this specific problem is just a small piece of a rather complex puzzle.

Our scenario is that we have many more or less independent development teams contributing to a common release through an integration stream (though not continuously). In our terminology, we call such a contribution a delivery. In our current home-grown SCM tool the delivery is represented by an entity conceptually equivalent to an RTC work item, which enforces formal control over the delivery workflow.

Trying to map this to RTC, it seems obvious that we should create a custom "delivery" work item type to which the development teams would attach their Scrum stories (or whatever equivalent work item types they use in their development process). As there is no such predefined work item type in RTC, my next set of questions would be if RTC has the functionality needed to enforce the necessary control over the delivery workflow. Hopefully this would be mainly yes or no questions;

1. Can I prevent submission of a delivery unless all related work is completed? I.e. can I prevent the delivery work item from entering a "submitted" state unless all its direct and indirect child work items are in a "completed" or equivalent state?

2. Can I "lock down" the delivery once it has been submitted? I.e;
2a. Can I prevent the addition of new direct or indirect child work items to the delivery work item once it has entered a certain "submitted" state?
2b. Can I prevent the addition of change sets to the delivery work item or any of its direct or indirect child work items once the delivery work item has entered a certain "submitted" state?

3. Can I prevent an integration stream from accepting anything but changes from a delivery work item having;
3a. A certain state (i.e. "approved")?
3b. A relationship to the integration stream through some "target release" attribute?

4. Can I view the integration stream in terms of the delivery work items that have been accepted into it?

Best regards,
Christer Palm

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 15 '10, 11:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Some of what you want to do can be achieved through available
("out-of-the-box") pre-conditions. For the rest, you would need to
write your own deliver post-conditions, using RTC process hooks (see
on-line documentation and jazz.net articles for guidance on that).

Currently, there is no way to tell the stream GUI to display parent work
items of a given type, rather than the immediate work items, but you
should feel free to submit that as an RFE. Also, there may be a way to
write a custom report to do so, but I'm not a reporting expert, so that
is just speculation on my part (in particular, telling the report to
recurse up through the parent relations until it finds a work item of a
given type doesn't sound like the kind of thing that reports are good
at, but that's also just speculation on my part :-).

Cheers,
Geoff

On 12/14/2010 1:53 PM, cpalm wrote:
gmclemmwrote:
Note that best practice is to accept those changes into a workspace,
so
you can confirm that this is a reasonable configuration, before you

deliver it. Once you have confirmed that the workspace content is
reasonable, you would use the standard "deliver" operation
on the
workspace to get those changes into the stream.

So I have phrased the work item in terms of new "accept"
functionality,
rather than new "deliver" functionality.
Actually, when I wrote "deliver" I was thinking of delivery
in a wider sense, i.e. getting the set of changes from one stream to
another. Sorry for the confusion!

gmclemmwrote:
I do not believe you can do what you are asking.
But I do agree it is a very reasonable thing to want to do, so I
have
submitted work item 148142 requesting this functionality.
OK, thanks!

Unfortunately, I believe this specific problem is just a small piece
of a rather complex puzzle.

Our scenario is that we have many more or less independent development
teams contributing to a common release through an integration stream
(though not continuously). In our terminology, we call such a
contribution a delivery. In our current home-grown SCM tool the
delivery is represented by an entity conceptually equivalent to an
RTC work item, which enforces formal control over the delivery
workflow.

Trying to map this to RTC, it seems obvious that we should create a
custom "delivery" work item type to which the development
teams would attach their Scrum stories (or whatever equivalent work
item types they use in their development process). As there is no
such predefined work item type in RTC, my next set of questions would
be if RTC has the functionality needed to enforce the necessary
control over the delivery workflow. Hopefully this would be mainly
yes or no questions;

1. Can I prevent submission of a delivery unless all related work is
completed? I.e. can I prevent the delivery work item from entering a
"submitted" state unless all its direct and indirect child
work items are in a "completed" or equivalent state?

2. Can I "lock down" the delivery once it has been
submitted? I.e;
2a. Can I prevent the addition of new direct or indirect child work
items to the delivery work item once it has entered a certain
"submitted" state?
2b. Can I prevent the addition of change sets to the delivery work
item or any of its direct or indirect child work items once the
delivery work item has entered a certain "submitted"
state?

3. Can I prevent an integration stream from accepting anything but
changes from a delivery work item having;
3a. A certain state (i.e. "approved")?
3b. A relationship to the integration stream through some "target
release" attribute?

4. Can I view the integration stream in terms of the delivery work
items that have been accepted into it?

Best regards,
Christer Palm

permanent link
Christer Palm (5641) | answered Dec 17 '10, 12:33 p.m.
Some of what you want to do can be achieved through available
("out-of-the-box") pre-conditions. For the rest, you would need to
write your own deliver post-conditions, using RTC process hooks (see
on-line documentation and jazz.net articles for guidance on that).

Thanks Geoff!

Judging from your response it sounds like the "delivery" work item idea would probably not be the best solution to our needs.

Is there a better way to do this?

Although not as nice, I experimented with trying to link the Change Sets directly to the "delivery" Work Item in addition to the Task they originally relate to, but the "delivery" work item still doesn't show up in the Pending Changes view. I guess that's because the they become Related Artifacts to the "delivery" work item rather that Change Sets.

I also realized that the History view lacks a Work Item mode like the one Pending Changes got, so there is no convenient way of looking at a stream in terms of the work items that it contains anyway, I guess?

Best regards,
Christer Palm

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 17 '10, 3:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Actually, all of the views are really showing you change-sets ... but if
there is a work item attached to that change-set, it displays the
Summary of the change set (in addition to the change-set commment, if
there is one). So in particular, if you have multiple change-sets
linked to a work item, you will see that work item listed multiple times
in the pending changes view (one for each pending change set).

Also, if there are multiple-work items attached to that change-set, the
GUI will pick one of them as the one to display (I don't think there is
any way you can control which one it picks).

Cheers,
Geoff

On 12/17/2010 12:38 PM, cpalm wrote:
gmclemmwrote:
Some of what you want to do can be achieved through available
("out-of-the-box") pre-conditions. For the rest, you
would need to
write your own deliver post-conditions, using RTC process hooks (see

on-line documentation and jazz.net articles for guidance on that).
Thanks Geoff!

Judging from your response it sounds like the "delivery"
work item idea would probably not be the best solution to our needs.

Is there a better way to do this?

Although not as nice, I experimented with trying to link the Change
Sets directly to the "delivery" Work Item in addition to
the Task they originally relate to, but the "delivery" work
item still doesn't show up in the Pending Changes view. I guess that's
because the they become Related Artifacts to the "delivery"
work item rather that Change Sets.

I also realized that the History view lacks a Work Item mode like the
one Pending Changes got, so there is no convenient way of looking at
a stream in terms of the work items that it contains anyway, I
guess?

Best regards,
Christer Palm

permanent link
Christer Palm (5641) | answered Dec 20 '10, 6:22 a.m.
Actually, all of the views are really showing you change-sets ... but if
there is a work item attached to that change-set, it displays the
Summary of the change set (in addition to the change-set commment, if
there is one). So in particular, if you have multiple change-sets
linked to a work item, you will see that work item listed multiple times
in the pending changes view (one for each pending change set).

OK.
What I had in mind was the "Show Work Items" modes in the Pending Changes view. In those modes, the Change Sets are grouped by Work Item, and it seems that you can also act on the Work Item level.

Best regards,
Christer Palm

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 20 '10, 10:08 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Ah yes, the "Show Work Items" Pending Changes mode (never use that
myself :-).

In that mode, all of the work items are shown, so your workaround (from
an earlier message in this thread) of also linking the change-sets
directly to the "delivery" work item should work ... i.e. go to the
Outgoing Work pending changes view, and select the Deliver operation on
the delivery work item. Did something not work when you tried this?

Cheers,
Geoff

On 12/20/2010 6:23 AM, cpalm wrote:
gmclemmwrote:
Actually, all of the views are really showing you change-sets ... but
if
there is a work item attached to that change-set, it displays the
Summary of the change set (in addition to the change-set commment,
if
there is one). So in particular, if you have multiple change-sets
linked to a work item, you will see that work item listed multiple
times
in the pending changes view (one for each pending change set).
OK.
What I had in mind was the "Show Work
Items" modes in the Pending Changes view. In those modes, the
Change Sets are grouped by Work Item, and it seems that you can also
act on the Work Item level.

Best regards,
Christer Palm

permanent link
Christer Palm (5641) | answered Dec 21 '10, 6:14 a.m.
Ah yes, the "Show Work Items" Pending Changes mode (never use that
myself :-).

In that mode, all of the work items are shown, so your workaround (from
an earlier message in this thread) of also linking the change-sets
directly to the "delivery" work item should work ... i.e. go to the
Outgoing Work pending changes view, and select the Deliver operation on
the delivery work item. Did something not work when you tried this?

Yes.
What I tried to do was to link the Change Sets to the Delivery Work Item in addition to the (Task or whatever) planning Work Item it was originally linked to.
While it's possible to have many Work Items linked to the same Change Set, only the original Work Item has the Change Set show up under the "Change Sets" heading in the Work Item's Links pane. Additional links from other Work Items instead show up under the "Related Artifacts" heading.

Obviously, the Pending Changes view shows only the Work Item that's got the "Change Sets" type of linkage.

However, although it defeats my evil plan to abuse it, I'd say that this behaviour makes a lot of sense.

Best Regards,
Christer Palm

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.