It's all about the answers!

Ask a question

Locking stream for code reviews


June Boston (1941033) | asked Jan 27 '15, 10:20 p.m.
retagged Oct 06 '17, 4:05 p.m. by Ken Tessier (84117)
 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


permanent link
David Lafreniere (4.4k7) | 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.

See:
-New & Noteworthy Mention: https://jazz.net/downloads/rational-team-concert/releases/6.0.2?p=newsDetails#stream-locking
-Stream/Component Locking Demo Video: https://www.youtube.com/watch?v=b8QwzwUF2ZY
-SCM Command Line Client 'set lock' command: https://www.ibm.com/support/knowledgecenter/SSCP65_6.0.4/com.ibm.team.scm.doc/topics/set_lock.html

Prior to 6.0.2, you can 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.

Also, prior to 6.0.2, another approach might be to add a deliver advisor in the process spec to restrict deliveries to particular streams. By protecting your stream by particular roles or users, you can effectively lock the stream down.
"http://jazz.net/library/article/215#protect_some" describes how to protect individual components in a stream, the same approach can be used to lock down the entire stream.

Michael Valenta selected this answer as the correct answer

One other answer



permanent link
Geoffrey Clemm (29.3k23035) | 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


Register or to post your answer.