Sometimes the appropriate response to reality is to go insane - Philip K Dick RSS 2.0
 Wednesday, March 26, 2008

Prompted by a discussion on the altdotnet yahoo group ... why I like broken builds ...

Some people try desperately to avoid breaking the build, by doing very infrequenet check ins (the number of broken builds per day drops dramatically, the time to fix each goes up though), or by trying to ensure their development environment is as close to the build environment as possible.

But a broken build is not a problem - it is an opportunity. A broken build allows you to identify a weakness, and to resolve it early.

The weakness might be in your architecture, it may be in your dependencies, or in your assumptions, or in your developer skill levels - but the whole point of having a continuous integration server is to fail fast and let you deal with the underlying problems rather than the specifics of the code you checked in.

 

Wednesday, March 26, 2008 9:14:57 AM (GMT Standard Time, UTC+00:00)  #    Comments [4] -
.NET | Agile | alt.net | C# | Continuous Integration | Design | Development
Wednesday, March 26, 2008 12:03:09 PM (GMT Standard Time, UTC+00:00)
fail fast works well when it doesn't take long to fix the build and it doesn't hold up anyone elses work...
Ollie Riches
Wednesday, March 26, 2008 1:13:47 PM (GMT Standard Time, UTC+00:00)
Would you prefer it to be all checked in on Friday afternoon and fix all the problems at once (probably over your weekend), or check in Monday morning and fix a few problems before moving to the next step :)
Casey
Tuesday, April 01, 2008 2:59:48 PM (GMT Standard Time, UTC+00:00)
Broken builds are fine but should be few and far between. It means that the developer didn't do his due dilligence before he checked his code in (maybe). Fostering an environment for broken builds means that you're sending a message that "it's okay to break the build". In my shops a broken build is an opportunity, but it needs to be addressed and not used as a norm. Having the build broken can lead to other problems that will impact the productivity of the entire team.
Tuesday, April 01, 2008 4:31:28 PM (GMT Standard Time, UTC+00:00)
OK ... maybe "like" was a bit strong, but compared to the alternatives that people go through to avoid breaking builds, I prefer it to be broken ...

Of course builds should be working as soon as possible, and a priority on a broken build is to fix it. I would still prefer that to be done to half a dozen changes checked in on Monday morning, than to try and do it to multiple branch merges on the Friday afternoon.
Casey
Comments are closed.
Navigation
Archive
<July 2008>
SunMonTueWedThuFriSat
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2008
Casey Charlton
Sign In
Statistics
Total Posts: 41
This Year: 13
This Month: 0
This Week: 0
Comments: 27
Themes
Pick a theme:
All Content © 2008, Casey Charlton
DasBlog theme 'Business' created by Christoph De Baene (delarou)