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. This is the case when all the commits are pushed to the master branch and the Git repository is wrongly used as backup system.

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 a 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 performed when the feature/fix is stable
• commits are not always pushed to the remote repository, but only when they add a significant and consistent piece of working code
• 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 (which should be temporary), their different versions guarantee that there are no conflict in the published artifacts.

Back to the CI guide.