As a developer on a team, when (if ever) is it reasonable to check in something which breaks one or more tests and causes the build to fail?
collaborate with someone else on it over time?
Another problem that can arise is the accumulation of potential debt by replacing functional code with incomplete code. If you aren’t able to make the timeline or the feature gets dropped for release, you now have a reverse merge on your hands. This could be particularly time consuming if others have been working in the same files that your work touches. On the other hand if you had been implementing it side-by-side and waiting to actually replace it until it worked, it would be no problem to ship the code in that state at any point if need be. Your deployment is more flexible and less error prone.
So how can you balance these tensions in an agile environment? I’d love any feedback that anyone has to provide. What are the reasons for prioritizing a passing build that I missed, and what other drawbacks exist?
Another problem that can arise is the accumulation of potential debt by replacing functional code with incomplete code. If you aren’t able to make the timeline or the feature gets dropped for release, you now have a reverse merge on your hands. This could be particularly time consuming if others have been working in the same files that your work touches. On the other hand if you had been implementing it side-by-side and waiting to actually replace it until it worked, it would be no problem to ship the code in that state at any point if need be. Your deployment is more flexible and less error prone.
So how can you balance these tensions in an agile environment? I’d love any feedback that anyone has to provide. What are the reasons for prioritizing a passing build that I missed, and what other drawbacks exist?
Also, Blogger ate my first attempt to post a comment here, and I felt somewhat better about deciding to do a post rather than answer here.
If your build is red, your first priority should be doing whatever it takes to make the build green.
If the bug you have found is serious, then that probably means that your team’s highest priority should be fixing the bug.
If it is not so serious, then you should back out the test until you have reason to believe it will pass.
Either way, you do not want to allow unrelated commits while the build is red. Red means that your application has burst beyond your control, and building further functionality atop a system that is already out of control is simply not a sustainable way to develop.
For this, the possibly-broken code must be separated from the stable version. Possible ways:
- develop on a branch until all tests pass, then merge it into HEAD
- set a “stable” tag in VCS which is moved up whenever a new feature is deemed stable
- add Make system switches to disable the possibly-buggy features; that way, you can have a “stable” build config which always works (also useful as autobuild/autotest target), and a “bleeding-edge” build config which is probably broken for quite a while.
IMO the latter two ways have the big advantage of making it easy for all developers to test some new unstable feature without having to manually merge its branch first.
If a test goes red but there’s nothing wrong with your production, then that’s an opportunity for you to learn how to write tests better! It’s obviously testing something you don’t care about, so you go in and rewrite it so that it only asserts on the things that matter.