Timeline for Should I intentionally break the build when a bug is found in production?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 9, 2012 at 18:02 | comment | added | AProgrammer | @WarrenP, there are sometimes other issues, but let's be clear, carelessness is the first reason why builds break. If you know that something break the build, why check it in? | |
| Feb 9, 2012 at 17:16 | comment | added | Warren P | This is a good example of why "breaking the build" becomes a toxic part of a workplace where CI devolves into merely "Blame Driven Development". I have sat in lots of meetings where the PHB starts whinging about "carelessness" as if that's why the build broke. In such an environment, you would hardly intentionally check in something that broken the build. Otherwise the PHB will get upset. Break the build, wear the cone of shame. What a crappy practice. | |
| Jan 20, 2012 at 12:42 | comment | added | sleske | @yarek: The regression tests can go into the codebase at any time, they just need to be ignored until the bug is fixed. I usually develop them while diagnosing the problem, because they can then double as a debugging aid. | |
| Jan 20, 2012 at 12:37 | comment | added | yrk | I'd suggest tohave regression unit tests enter code base as part of the bugfix, not earlier. | |
| Jan 20, 2012 at 12:16 | comment | added | MattDavey | "list of failing tests isn't a substitute for a bug tracking system" +1, also a very good point :) | |
| Jan 20, 2012 at 11:47 | history | answered | AProgrammer | CC BY-SA 3.0 |