Work Around Code Review?
A Developer checks-in a change set, then it is reviewed and has a must fix attached to it. The Dev then uploads a new change that fixes the must fix in the first change set, the work item is approved. The Dev then decides/accidentally delivers the first change set with the unapproved code to the stream.
How do we stop the Dev from doing this?
|
Accepted answer
There is currently no way to prevent this situation. It sounds like in theory a process advisor/precondition could be created for the deliver operation, which would make sure that the user delivers all change sets associated to a particular work item - all at the same time, otherwise it would fail... however in practice I can't see that many teams would want to enforce such a check.
This sounds more like a generic issue though in that there could be a case where an author has two change sets, and the code review was conducted which also had no issues (or even no code review was conducted), and the author could accidentally deliver only one of the two change sets, which in the end results in 'incomplete' code delivered to the stream. Note: If this situation is of some concern, then this could be made into a manual process by also 'informally' requiring a approval or verification on the work item to ensure that all changes have been delivered. Fortunately, the actual checking of this would be pretty straightforward using the Locate Change Sets editor. Michael Valenta selected this answer as the correct answer
|
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.
Comments
Can you clarify one thing, I'm confused with the ordering of events in your question. Your first sentence says the developer already delivered the [first] change set, and the last sentence says he also accidentally delivers the first change set.
Sorry David, I got a little mixed up. When I said 'deliver' the first time, I meant 'checks-in.'