How to stop worrying about broken builds

In traditional CI workflow, if you checked in something and broke the build, you would block the whole team. You might end up checking in less frequently. Or the team need to enforce some kind of check in policy. These do not make any sense to me. CI is supposed to give me rapid feedback, and broken builds are also good feedback!

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

By using the Git plugin for Jenkins to monitor all the branches on the local repository. Whenever a developer pushes to to repository, Jenkins will see the changes and try to merge it into the stable branch. And if you apply feature branching workflow in your team, broken build are on longer a blocker for the team, they are only a blocker for the developer working on the feature branch.

And if you integrate Sonar in your CI process, you will be able to use sonar to verify each feature branch before merging to the stable branch! Don’t you think that’s the right way of doing CI?