Parallel builds - same build definition and build workspace

Morten Madsen (305●28●46) | asked Oct 15 '13, 1:18 p.m.

Hi, I can understand that parallel builds are supported, if you start several build engines with each a unique id, but supporting the same build definition.

But what happens with the shared build workspace? If build 1 accepts new changes and commences build, then build 2 accepts new changes not included in build 1 and commences.

Wont the changed state of the workspace confuse and maybe break the build for build 1?

Accepted answer

permanent link

Scott Cowan (966●3●10) | answered Oct 15 '13, 2:36 p.m.
JAZZ DEVELOPER

Hi Morten,

After build 1 accepts new changes it retains a last modified timestamp for each component in the workspace and verifies it hasn't been modified before fetching each component. If build 2 accepts more new changes to a component build 1 has yet to fetch, build 1 will fail upon fetching it.

So, build 1 may fail for this reason, but build 2 will carry on. Build 1 however, will not successfully fetch an inconsistent workspace.

Scott

Morten Madsen selected this answer as the correct answer

Comments

Morten Madsen commented Oct 15 '13, 3:09 p.m.

Thanks a lot :) - nice to have my suspicions verified. I solved this by creating more build definitions each having a separate workspace.

We're also using home grown ant tasks for accepting only changes that has a work item with a certain state, so it gets quite complicated when running with 4+ builds. At the beginning of the build, the build workspace will be balanced against the target stream (next environment stream in promotion level) and upon ending, it will only deliver work items in which all change-sets has been built successfully.

It's all about the answers!

Related questions

Parallel builds - same build definition and build workspace

Accepted answer

Your answer