When I started building a continuous integration server, I ran across the statement "It's bad to break the build [of the code]." After finishing that project I came to the conclusion that
So my question is in the spirit of #2: why is breaking the build a bad thing?
Because if other people check out your broken changes, they won't be able to work, or if they do they will do so less efficiently.
It also means you're not properly testing your changes before you commit, which is key in CI.
Because it means someone has done something bad (or at least, some changes have clashed) and you can no longer build and deploy your system.
It you break the build as has happend to me yesterday. When your team-mates try and use the sourcecode. It will not build. Therfore they will struggle to test the work that they are doing. It get worse the bigger your team.
Once builds start breaking, people get reluctant to get the latest changes, and you begin the deadly spiral towards Big Bang integration of changes.
Breaking the build means that you committed code to a shared repository that either (a) does not compile, or (b) does not work (fails unit tests). Anyone else who's developing from that shared repository is going to have to deal with the broken code you committed until it is fixed. That will cause a loss of productivity for the entire team.
From Martin Fowler http://martinfowler.com/articles/continuousIntegration.html
The whole point of working with CI is that you're always developing on a known stable base. It's not a bad thing for the mainline build to break, although if it's happening all the time it suggests people aren't being careful enough about updating and building locally before a commit. When the mainline build does break, however, it's important that it gets fixed fast.
Breaking the build has dire implications for the project schedule (and the blood pressure of team-mates) => Other developers who then get latest version can no longer build there own changes, delaying them => Continuous integration will break, meaning that formal testing can be delayed
Many version control tools (e.g. TFS) can prevent developers from checking in code which does not compile or pass unit or code analysis tests.
I don't think breaking the build is necessarily a bad thing, as long as there is a well-known, working branch or tag in the repository. That said, make your own branch in the repository if you know your code is going the break the build today, but you will fix it next week. Then later you can merge back into trunk.
Be very careful in labeling "Breaking the Build" as a bad thing. It is something that needs immediate attention, but it is also a very normal and expected part of the development cycle. This is why Continuous Integration is so useful -- it tells you immediately when the build is broken, and what change set caused it. It helps you get back on track quickly.
If your culture penalizes "Breaking the Build", then you are in danger of cultivating a toxic work environment. Again, consider it to be something that needs immediate attention, but don't label it as "bad".
Because if other people checkout the changes, they won´t be able to work...
This image is copyrighted to Geek & Poke under a Creative Commons License
Surely the whole point of continuous integration is to identify problems early. Daily or more frequent check ins are required to reduce conflicts to a manageable size.
You should get an up to date copy of the repository and build locally. This will tell you if your proposed check in will break the build. You resolve any issues and then check in.
In this way the integration issues are kept local and easy to fix.