How to find out which delivery broke the build?
In order to find out which delivery broke the build, a potential solution would be then to trigger one build after each delivery. This question is better described in the following issue:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=308841
It has been suggested to use Personal builds instead, so that every developer can request its own personal build, running on the build server, before delivering the change sets.
This is a very interesting feature, indeed! However, I believe it doesn't solve our problem because the builds in this case aren't cumulative.
Our builds take few hours each, and it would happen very often that a developer A requests a Personal build while developer B is already running his one. When A's build finishes, B would have already delivered his change sets, so that A would be required to accept them and request a personal build once again (change sets from A or B alone may not break the build, but together they can break it.). In a larger scale (+ developers, + build duration) it would be difficult to manage.
Instead, we need change sets from dev A to be available to every other developer (that is, delivered) immediately before his build starts. So, when dev B is ready to deliver, he will first accept the incoming change sets (which could be green or not) and deliver the merged code. A build with change sets A+B would be queued right after the build with change sets A.
Is there any strategy to solve the issue above?
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=308841
It has been suggested to use Personal builds instead, so that every developer can request its own personal build, running on the build server, before delivering the change sets.
This is a very interesting feature, indeed! However, I believe it doesn't solve our problem because the builds in this case aren't cumulative.
Our builds take few hours each, and it would happen very often that a developer A requests a Personal build while developer B is already running his one. When A's build finishes, B would have already delivered his change sets, so that A would be required to accept them and request a personal build once again (change sets from A or B alone may not break the build, but together they can break it.). In a larger scale (+ developers, + build duration) it would be difficult to manage.
Instead, we need change sets from dev A to be available to every other developer (that is, delivered) immediately before his build starts. So, when dev B is ready to deliver, he will first accept the incoming change sets (which could be green or not) and deliver the merged code. A build with change sets A+B would be queued right after the build with change sets A.
Is there any strategy to solve the issue above?
2 answers
One approach is to set up an intermediate 'staging' stream, with a corresponding build. You can then set up post-build deliver in that build to deliver/promote the accepted changes to the "real" integration stream but only if the build is green. That is the original use case for post-build deliver.
Comments
