Builds should never fail! (for long...)
After arriving to work and checking my e-mails I decided to check in on my previous team's results on the continuous integration system. Guess what? The build had been broken for 10 days!
Continuing to develop on top of a broken build is dangerous as typically an error in the build process hides several other problems. Only the problem that causes the build to fail is visible, but that may only be the tip of the iceberg. Do you know if the current error is the tip of the iceberg?
Also, nothing justifies having a broken build. Don't get me wrong, there are many excuses to have a build broken:
1- I'm sick, not at the office! (someone else needs to take the ball, that's why the build results are available to the WHOLE TEAM!!)
2- I'm just too damn lazy! (humm, should this person be in the team?)
3- I don't know how to fix the build! (someone else needs to help!)
4- It's ok to have that unit test fail because we are working on something that makes it fail for now! (If the build has been broken for more than a few hours this normally is a sign that you don't know what you are doing because you can no longer assess the consequences of your changes!)
5- That unit test is obsolete, it should be removed. (what are you waiting for?!?)
6- Continuous integration sucks and I don't care if the build is broken (there are bigger problems then the broken build in this team!)
7- I don't believe that having continuously working software helps the development process in any way (boy, are you in for a religious fight or what!)
Even though I could come up with these excuses in just under 5 minutes, it does not mean that any of them justify having a broken build!
The continuous integration system is our hourly/daily feedback loop on the quality of the code that is delivered. If that stops working we are back to waterfall, even if an "iteration-length" waterfall instead of a "project-length" waterfall.
What happens at the end of the iteration if the build is broken until then? A lot of testing! Testing only at the end is bad because it destroys the visibility to your progress, and the continuous integration system helps you maintain that visibility by providing some "validation" on the code that you are developing.
If you are asking yourself "how could I avoid broken builds?", take a look at this post.
at
10:07
Continuing to develop on top of a broken build is dangerous as typically an error in the build process hides several other problems. Only the problem that causes the build to fail is visible, but that may only be the tip of the iceberg. Do you know if the current error is the tip of the iceberg?
Also, nothing justifies having a broken build. Don't get me wrong, there are many excuses to have a build broken:
1- I'm sick, not at the office! (someone else needs to take the ball, that's why the build results are available to the WHOLE TEAM!!)
2- I'm just too damn lazy! (humm, should this person be in the team?)
3- I don't know how to fix the build! (someone else needs to help!)
4- It's ok to have that unit test fail because we are working on something that makes it fail for now! (If the build has been broken for more than a few hours this normally is a sign that you don't know what you are doing because you can no longer assess the consequences of your changes!)
5- That unit test is obsolete, it should be removed. (what are you waiting for?!?)
6- Continuous integration sucks and I don't care if the build is broken (there are bigger problems then the broken build in this team!)
7- I don't believe that having continuously working software helps the development process in any way (boy, are you in for a religious fight or what!)
Even though I could come up with these excuses in just under 5 minutes, it does not mean that any of them justify having a broken build!
The continuous integration system is our hourly/daily feedback loop on the quality of the code that is delivered. If that stops working we are back to waterfall, even if an "iteration-length" waterfall instead of a "project-length" waterfall.
What happens at the end of the iteration if the build is broken until then? A lot of testing! Testing only at the end is bad because it destroys the visibility to your progress, and the continuous integration system helps you maintain that visibility by providing some "validation" on the code that you are developing.
If you are asking yourself "how could I avoid broken builds?", take a look at this post.
RSS link
0 Comments:
Post a Comment
<< Home