If you haven’t done so already, you will. Soon. It’s inevitable. No matter how careful you are, no matter how meticulous your check-ins, you will eventually be the developer who Breaks the Build.

Most developers fear becoming the Build Breaker. It’s not so much that they’d be responsible for hours of lost productivity, lost testing, lost testing time, and that sort of thing, it’s the “other” consequences. To help prevent broken builds, development organizations have put together penalizing procedures that are designed to embarrass and humiliate the Build Breaker. It’s almost always something fun and silly – the Build Breaker has to bring bagels to the next team meeting, or the Build Breaker Beanie Cap gets passed down from the last Build Breaker and must be worn for a week straight – but it works. Nobody wants to be The Build Breaker.

Aaron’s team and project had grown quite a bit, and they were really starting to feel the pinch of broken builds. They had an automated build and deploy system that ran each and every night. When a developer checked-in code that caused compiler errors, that meant there’d be no build for the day, no testing for the day, and a lot of grumpy developers and testers. It didn’t happen too often – once, maybe twice a month – but it was often enough that something had to be done.

At this point, the development manager would normally step in and implement some silly Build Breaking policy. And that’s exactly what Aaron’s manager did. Well, sort of. It was more of a Check In policy.

Before any check-ins to the source repository could be made, the build had to be verified as compilable and pass all unit tests. And since developers were supposed to do that prior to a check-in anyway, the manager insisted that he be physically present at every proposed check-in. If didn’t see the code compile and be tested, then no code could be checked-in. Period.

The new Check-In procedure had an immediate impact on productivity. With a few dozen developers and a single development manager, development had become about as fast as molasses going uphill in January. Complaints were made, alternative solutions were offered, but the development manager stuck to his guns: “The integrity of the source repository must be preserved! We cannot have code in our repository that causes tests to fail!”

As the months passed by, developers found themselves waiting days at a time for the development manager to review their build and unlock the repository.

Things have improved a bit since the Check-In policy was first instated, but it remains mostly the same. These days developers can ask any one of three team leads to watch their build compile, watch them run unit tests, and then have them check-in the code. The good news is that not a single build has been broken yet. And in a few more months, they might just implement their first new feature.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!