Pretty much any organization that does internal software development these days does so with a team of multiple developers. Your development team breaks down a project into tasks that can be done in parallel, much like how those multi-core CPUs in your computers allow for processes and threads to work in parallel. The goal is to get more work done in less time (theoretically).
And just like how a multi-threaded application needs some mechanism to synchronize its actions, developers synchronize their work using a version control system. Then they validate that work using a continuous integration system to compile, analyze, and test their changes to the code base.
Of course all of your developers follow best practices, like making sure their code changes compile locally, all tests pass, etc. This is easy for them to do because of your well thought out build system (right?!). But every now and then a change makes it in that… BREAKS THE BUILD. Someone checked in a change that caused the compilation to fail or a test to fail, causing your continuous integration system’s status board to go red, error mails to fly out, alarms to start going off, sirens to blare… before you know it, dogs and cats are living together and there is mass hysteria.
But is it really that big of a deal?
The whole point of a continuous integration system is in its name: to continuously integrate your application’s code base. It is there to catch integration problems as early as possible. Of course there are exceptions, but most of the time a build break should be seen as nothing more than a minor inconvenience. You and your team should want builds to break. A build break is great news, it means a problem was caught right away.
And even if you didn’t configure your continuous integration system to alert other developers as loudly as possible, with proper communication within the team, you shouldn’t be afraid to let everyone else know what happened. Raise your hand, admit the build break may have been due to your change, start investigating the issue, and start working on a resolution if necessary. Take ownership of the build break and try to fix it. Relax and take a deep breath. It’s not the end of the world, it’s just your continuous integration system fulfilling its purpose.
Of course if you’re breaking the build nearly every time you commit your code changes, it may be time to review your own local development practices. But don’t let build breaks scare you or your team into implementing some draconian, complicated branching strategy to isolate changes. Remember, every time you branch you have to merge. Every time you create a branch, you make a conscious decision to delay integration. And delaying integration undermines your continuous integration system’s entire purpose: which again, is to identify problems with the code base – compilation errors, testing errors, etc. – as quickly as possible.
Keep your branch model simple. By following an SCM pattern line like the Mainline pattern and relying on your continuous integration system to validate and integrate your changes, you reduce your team’s merging and synchronization efforts.
You want to experience build breaks; they are a normal part of a healthy application life-cycle. Do not fear build breaks!
