How many builds?

The biggest risk of a non-properly configured Continuous Integration pipeline is to trigger too many builds and transform the pipeline into something we can call Continuous Building. Parallel builds of the same project that interfere with each other and may create inconsistent situations are very common.

In this guide, we set up a few procedures to prevent this misbehavior. Some of them assume a proper usage of Git from the user.

Here's a summary of these practices:

• the Jenkins project builds always the master branch
• if Jenkins project is configured to build a second branch, this branch must generate a software artifact with a different version than master branch
• the development of new features and bug fixing are done in dedicated branches (task branching)
• merges into master branch are done when the feature is stable
• the master branch MUST be always in a releasable state

Following them, builds are triggered only when a stable feature is merge into master, while commits in the other branches do not involve Jenkins. If two branches are built at the same time in a Jenkins project, their different versions guarantee that there are no conflict in the published artifacts.

Back to the CI guide.