How to find out which delivery broke the build?
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
Comments
Thanks for the answer @nedgar, though I think it still doesn't solve the problem...
The main idea isn't to keep a green stream, but to identify which deliver broke the build.
For instance, if we have a polling of interval N, and 5 deliveries are performed in a single interval, the next build request will include the change sets of all those deliveries...
If it breaks, we still don't know which delivery caused that, no matter if the post-build delivery in staging stream was triggered or not.
A delivered. A was built successfully
B delivered. A+B was build successfully
C delivered. A+B+C build failed... something is wrong with the latest change sets from C OR with the merging process from the stream to C.
In your example, it would be clear that C was the cause of the failure. The post-build deliver doesn't do a merge -- it does a replace of the component(s) into the target stream. Your point about multiple deliveries within the timeframe of a single build is still valid though, and there could still be other integration issues though, e.g. if multiple builds are pushing to the integration stream for different components.