Parallel Jobs Build

This pattern is in fact quite similar to multiple single job build in its approach and can be applied in that context as well. But this doesn't suffer from the limitation caused by lack of synchronization on materials. Since the group of jobs are bound together, even when a job succeeds the integration build is considered successful only when the group is successful. The same cannot be done in multiple single job build because the concept of group doesn't exist. Group is also important because the downstream builds needs to understand the concept of group of jobs. In above example Regression stage would start only when Developer stage is successful.

This is where second generation of continuous integration tools come in. Although you should check whether and how they achieve this, because not all might have this support. (Go provides this support extremely well.) One can assign multiple agents on which these jobs can run independent of each other.

Limitation

Parallel job suffers from duplication of work across different jobs. This is because of dependency between different components that these jobs build. This can be tolerated as long as there is enough hardware to take care of the build. So in the example below, in order to ruun job for component B, one needs to run a.compile, b.compile and b.test. (Of-course in non-compiled languages this wouldn't be the case.) This limitation can be overcome by:

• Optimized Parallel Jobs Build
• Combining multiple components under single job. For example, build of components B and C [a.compile, b.compile, c.compile, b.test, c.test] can be done in a single job, if required.

Some people don't like the idea of duplication and try to eliminate it by using pipelined builds. Pipeline build is not suitable for splitting one build as explained in that pattern. This pattern is powerful in-spite of duplication because it enables the end objectives which are faster builds and CI build same as local build. Optimizations should be done only if there is hardware constraints than for design purity reasons.