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
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.
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.
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.