{"id":113,"date":"2009-06-23T16:35:01","date_gmt":"2009-06-23T20:35:01","guid":{"rendered":"http:\/\/www.dankulp.com\/blog\/?p=113"},"modified":"2009-06-23T16:35:01","modified_gmt":"2009-06-23T20:35:01","slug":"dont-break-the-build","status":"publish","type":"post","link":"https:\/\/www.dankulp.com\/blog\/?p=113","title":{"rendered":"Don&#8217;t break the build!"},"content":{"rendered":"<p>Throughout my career as a developer, one &#8220;mantra&#8221; that has been deeply ingrained into my brain is &#8220;commit away, but DON&#8217;T BREAK THE BUILD!&#8221;.   Breaking the build can include things like breaking checkstyle\/pmd checks, committing code that doesn&#8217;t even compile, having unit\/system test failures, sticking dependencies in the poms that don&#8217;t exist in declared repos (example: depending on a SNAPSHOT you built locally) , etc&#8230;    Bunches of things.   <\/p>\n<p>Breaking a build on something you&#8217;re the only one working on is usually not a huge issue.  Just commit a fix at some point and no-one will ever know.   However, when working with a large team or working on OpenSource where people all over the world could be building it, break a build can be a serious issue.  If the build is broken, you can easily have MANY engineers wasting a lot of time trying to debug something they shouldn&#8217;t be.   That can be quite &#8220;expensive&#8221;.    <\/p>\n<p>For example, if I run the tests and see a test failure, I assume one of my changes is the cause of that.  Thus, I start debugging and try and figure out what I did.   I shouldn&#8217;t be trying to debug into tests that aren&#8217;t caused by my changes.   The code base should be stable and just work.   <\/p>\n<p>Unfortunately and apparently, there are a lot of people that don&#8217;t believe the same as I do.  The <a href=\"http:\/\/wiki.hudson-ci.org\/display\/HUDSON\/The+Continuous+Integration+Game+plugin\">Hudson Continuous Integration Game plugin<\/a> provides an interesting way to see who believes what.   Basically, for each build done in Hudson, the plugin assigns a score.   If the build succeeds cleanly, all developers that contributed changes get a point.   If the build fails spectacularly (fails to even compile), it&#8217;s -10 points.   A failing unit test is a minus point.  Fixing a failing test is a plus point.  etc&#8230;   Thus, over time, people that tend to break things end up with less points (even negative) and those that tend to fix things and\/or commit clean code end up positive.  Obviously, it&#8217;s not perfect.   People that commit a LOT can earn higher scores as they can get one point per commit.   I commit a couple times a day.   Thus, I have potential to get more points than someone who only commits a couple times a week.   <\/p>\n<p>Looking at the <a href=\"http:\/\/hudson.zones.apache.org\/hudson\/cigame\/\">Apache Hudson Instance Leader Board<\/a>, you can see quite a range of scores.    IMO, there are entirely too many people with negative scores.   Something for those people to start working on.  Get to work!   \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Throughout my career as a developer, one &#8220;mantra&#8221; that has been deeply ingrained into my brain is &#8220;commit away, but DON&#8217;T BREAK THE BUILD!&#8221;. Breaking the build can include things like breaking checkstyle\/pmd checks, committing code that doesn&#8217;t even compile, having unit\/system test failures, sticking dependencies in the poms that don&#8217;t exist in declared repos [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[2],"tags":[],"_links":{"self":[{"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/113"}],"collection":[{"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=113"}],"version-history":[{"count":3,"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/113\/revisions"}],"predecessor-version":[{"id":116,"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/113\/revisions\/116"}],"wp:attachment":[{"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dankulp.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}