Build Concurrency

Version 2 by Robin Shen
on Aug 10, 2009 20:19.

<< Changes from 1 to 2

compared with

Version 3 by Robin Shen
on Aug 10, 2009 22:50.

Changes from 3 to 4 >>

Key

These lines were removed. This word was removed.

These lines were added. This word was added.

There are 1 changes. View first change.

		It is good pratice that each change set submitted by the developer is verified/tested at build server to ensure it does not break the basic functionalities. In a busy team, developers may submit their code changes frequently to cause many builds being requested at the build server. It is important to be able to run these builds concurrently to get fast feedback for the submitted changes.

		Build concurrency in QuickBuild is determined by [workspace\|configuration workspace] access: if two builds tries to access the same workspace in the same time, only one build will be allowed to use that workspace. The second build will wait until the first build has finished using that workspace. Since different configurations use different workspaces on the same node, two builds from different configurations can always run concurrently unless you limit the concurrency by controlling number of workers in the build queue. Things get complicated for builds from the same configuration.