Locking stream for code reviews
June Boston (194●30●38)
| asked Jan 27 '15, 10:20 p.m.
retagged Oct 06 '17, 4:05 p.m. by Ken Tessier (841●1●7)
Hello,
For the code review process, we want to freeze a stream. We will likely take a snapshot and link the Code Review work item that snapshot, but we also want to prevent delivery to the team's stream so they cannot push any more code up. I understand that if a stream's owner is set as the project itself, we can restrict delivery to certain widgets on a team by team basis for each stream. In order to to lock the stream when a code review is happening, we need to go into the Process Configuration for Operational Behaviour under Team Configuration and change the "Restrict Change Set Delivery to Component" to allow only a Review team instead of a developer team, or perhaps someone with a Reviewer role.
Doing this is not very intuitive and fairly cumbersome to do on a regular basis, not to mention the need for privilege to modify the Process Configuration. Is there a way to trigger this change and then flip it back as a regular CLM user, or would we have to script something?
Thank you,
June
|
Accepted answer
David Lafreniere (4.8k●7)
| answered Oct 05 '17, 1:11 p.m.
FORUM MODERATOR / JAZZ DEVELOPER edited Oct 05 '17, 4:11 p.m. In RTC 6.0.2 we added a feature that lets you lock streams and components to prevent deliveries to the files in those streams or components. Stream and component locks work in a similar manner to file locks but apply to the entire stream or the entire component in a stream. When a stream or component is locked, any attempted deliveries by users who do not own the lock will fail with an appropriate error message. The user that holds the lock can still perform deliveries to the stream. A lock does not only prevent deliveries, it also prevents any operation that affects the files in the locked component or stream. For example, a component replace is also prevented.
Michael Valenta selected this answer as the correct answer
|
One other answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 28 '15, 12:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
One approach is to use iteration-type specific processes. For example,
- in the timeline where you want to have reviews, create a "review" iteration, and set its iteration type to be a new iteration type, "review-iteration-type" - in the Team Configuration section of the Process Configuration page, modify the Operation Behavior to be whatever you want the process to be during reviews - When you are ready to do a review, set the current iteration to be the "review" iteration. - When you are done with the review, set the current iteration back to the appropriate development iteration. Comments
June Boston
commented Jan 28 '15, 7:58 p.m.
This could be workable, but in a complex project with many streams, if only one stream needs reviewing this would lock the whole stream. I suppose we could have independant review iterations for each stream that gets reviewed. |
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.