Work Items, Approvals and delivery.
I am just getting started with the idea of work items in RTC. I do not follow the idea of Approvals for Work Items.
Suppose, a work item requires my approval and I have rejected it. This work item has a couple of change sets associated to it. Then, because the approval was not provided, can this work item be still delivered (via, lscm deliver -c <work_item>) ? It would be interesting to know, if one can enforce a policy of delivering only those change sets that have associated work items for which approvals are in place.
Suppose, a work item requires my approval and I have rejected it. This work item has a couple of change sets associated to it. Then, because the approval was not provided, can this work item be still delivered (via, lscm deliver -c <work_item>) ? It would be interesting to know, if one can enforce a policy of delivering only those change sets that have associated work items for which approvals are in place.
Accepted answer
If you are using the RTC SCM and Work Items, you can do exactly what you want: require an approval before delivering change sets.
What is RTC SCM and Work Items ? I am using RTC client. :?:
RTC SCM = Rational team concert source code management (like subversion)
Work items are the "requirements" for your project, such as bugs, improvements and so on
What you want to do (as i understand it) can be configured in the project area settings.
In the Eclipse Client:
Go to Process configuration and in the Tree select "Team Configuration->Operation Behavior"
There you can select the operation "Sourcecontrol management->Deliver" for your specific roles and add a precondition.
For example "require work item Approval" what is think is what you needed.
I don't find these configuration possibilities yet in the web client on my own,
if somebody, please let me know ^^
I am using RTC 3.0.1 in german, sorry if the names doesn't fit ^^
Comments
Is the 'Require Work Item Approval' same as right-click on a change-set (associated with a WI already) and click on 'Submit for review' ? Or, is it same as taking approval from a person whose name was added as an Approver when the WI was created ? In either case, I am not able to deliver the change-sets. There could be an issue with the role associated with my ID; but, otherwise, I just wanted to know the meaning of 'Require Work Item Approval' ?
9 other answers
If you are using the RTC SCM and Work Items, you can do exactly what you want: require an approval before delivering change sets.
The Jazz team does exactly that: as we move closer to shipping a product, we require more and different kinds of approvals.
Martha
Jazz Developer, Process Component
The Jazz team does exactly that: as we move closer to shipping a product, we require more and different kinds of approvals.
Martha
Jazz Developer, Process Component
I am just getting started with the idea of work items in RTC. I do not follow the idea of Approvals for Work Items.
Suppose, a work item requires my approval and I have rejected it. This work item has a couple of change sets associated to it. Then, because the approval was not provided, can this work item be still delivered (via, lscm deliver -c <work_item>) ? It would be interesting to know, if one can enforce a policy of delivering only those change sets that have associated work items for which approvals are in place.
I have a follow-up question.
Looking at the command for associating change sets with WI, I think, the correlation is one WI to many change sets; than the other way round. Is this correct ?
Assuming the above to be correct, suppose there are change sets C1, C2, C3, etc. with various developers all associated with one WI, say, W1. One of the developer has a change set C3 associated with W1. If this developer does the delivery at the WI level for W1, only C3 would get delivered and not all of C1, C2, etc. Is this correct ?
Looking at the command for associating change sets with WI, I think, the correlation is one WI to many change sets; than the other way round. Is this correct ?
Assuming the above to be correct, suppose there are change sets C1, C2, C3, etc. with various developers all associated with one WI, say, W1. One of the developer has a change set C3 associated with W1. If this developer does the delivery at the WI level for W1, only C3 would get delivered and not all of C1, C2, etc. Is this correct ?
The work-item/change-set relation is many-to-many.
WRT "delivery at the work item level", what specific operation (from
which client) did you have in mind?
Cheers,
Geoff
On 10/17/2011 9:23 AM, programergosum wrote:
WRT "delivery at the work item level", what specific operation (from
which client) did you have in mind?
Cheers,
Geoff
On 10/17/2011 9:23 AM, programergosum wrote:
I have a follow-up question.
Looking at the command for associating change sets with WI, I think,
the correlation is one WI to many change sets; than the other way
round. Is this correct ?
Assuming the above to be correct, suppose there are change sets C1,
C2, C3, etc. with various developers all associated with one WI, say,
W1. One of the developer has a change set C3 associated with W1. If
this developer does the delivery at the WI level for W1, only C3
would get delivered and not all of C1, C2, etc. Is this correct ?
Hi Geoff,
I was referring to the command line option of doing the delivery.
BTW, I ran into another issue. I was able to deliver changes at a work-item level when there was only a single change set. But, when there are more than one change set for a given work-item and I try to deliver at work-item level, only one of them (probably, the latest change set) gets delivered.
Is such type of delivery not allowed ? To me, it seems to be a nice way of collecting different change sets, associating with one work item and then delivering them at one shot.
I was referring to the command line option of doing the delivery.
C:\RTC-SysTest-Build>scm help deliver
Help on deliver
Delivers changes from source workspace (default is current remote workspace) to target workspace (default is default collaboration of source workspace). The changes to deliver can be scoped in one of three ways: all changes in a workspace (default), all changes in a set of one of more components (using "-C/--components"), or a specific set of changes (by specifying the change set aliases, UUIDs, or work item numbers using "-c/--changes").
BTW, I ran into another issue. I was able to deliver changes at a work-item level when there was only a single change set. But, when there are more than one change set for a given work-item and I try to deliver at work-item level, only one of them (probably, the latest change set) gets delivered.
Is such type of delivery not allowed ? To me, it seems to be a nice way of collecting different change sets, associating with one work item and then delivering them at one shot.
C:\RTC-SysTest-Build>scm pc
Workspace: (1032) "nsubrahm_SysTest" <-> (1033) "Stream_SYSTEM_TEST_WIM"
Component: (1034) "RTCTEST" <1033>
(1037) ---$ 198315 "Promote HTTP project related code to ST." - "mani>
(1036) ---$ 198315 "Promote HTTP project related code to ST." - "mani>
C:\RTC-SysTest-Build>scm deliver -r igartc03 -c 198315
Delivering changes:
Workspaces:
(1032) "nsubrahm_SysTest" --> (1033) "Stream_SYSTEM_TEST_WIM"
Components:
(1034) "RTCTEST"
ChangeSets:
(1039) "manidcha_198315_1039_19-Oct-2011.14:40:26"
Deliver command successfully completed.
On jazz.net, Select Projects, Select "Rational Team Concert", and on the
right side of the resulting page, you'll see "Submit a bug or request".
Selecting that will jump you to the URL:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.newWorkItem
Or you can just use that URL directly (:-).
Cheers,
Geoff
On 10/19/2011 9:38 AM, programergosum wrote:
right side of the resulting page, you'll see "Submit a bug or request".
Selecting that will jump you to the URL:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.newWorkItem
Or you can just use that URL directly (:-).
Cheers,
Geoff
On 10/19/2011 9:38 AM, programergosum wrote:
tmokwrote:
That sounds like a bug that it won't deliver both of those change
sets. You should open a defect against Source Control CLI.
Thanks Tim. How does one raise a defect ? ( :oops: Very new to RTC
.. ! )