Confidence in Personal Build result in large, high change rate teams
If developers request a personal build, they can use the result to determine whether their changes would break the team build, before they deliver to the team stream.
This is possible because the diff between the private workspace and the team stream is confined to the changes the developer has made. Therefore, a successful personal build suggests it is safe to deliver to the team stream.
This of presumes that nobody else has delivered to the team stream since the personal build was requested.
In large teams with high rates of change it may not be safe to make this presumption.
Even less so with large products where build times are more than just a few minutes.
What practices, and/or RTC capabilities (available in RTC 5.0.2) can help in this scenario?
|
Accepted answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Sep 04 '15, 3:17 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You can turn on the Deliver(server) precondition "Require workspace to be caught up before delivery".
But for teams with a high rate of change, this could significantly slow down delivery. There is no magic bullet that solves this problem. For teams with a high rate of change, the purpose of the personal build is to decrease the likelihood of a delivery breaking the team build, but not to eliminate the possibility. Ben Williams selected this answer as the correct answer
Comments Thank you Geoff. Perfectly reasonable response. I understand there is no panacea here, but awareness of our options around the use of capabilities such as 'Require workspace to be caught up before delivery' certainly will help in determining how best (to start) to evolve our configuration to support the working models we're adopting. |
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.