Occasionally in some discussions on Agile the topic of Nightly Builds comes up, and while I will agree that its something that should be done during a sprint, and while its mentioned in a couple of newer editions on the methodology I just see it as something that needs to be done. You don't need to be on a Scrum Team or on an Agile Sprint to see the value in a nightly build, if your code is building every night then it means people are doing their work and verifying that things work properly, nothing more special than that. Methodologies are great to build a framework around, and often give high level management some way to say they are doing something that is hot and on topic, or allow them to utilize yet another buzzword. Outside of that nightly builds are good for everyone.
The gains are immense, not only knowing that any day someone can check out the source tree and get the code to build in their environment but once you have taken the step of having a build happen then you can go onto the next step of automated testing. Whether its a suite of Unit Tests or an automated Smoke Test, unless code is building you are not taking that next step, adding those steps allows one to have a good deal of confidence against the code checked in. Having tests run every night allows you to know that your code is good in the source tree not only because it builds but that its passing a set of tests deemed necessary for the code to always pass. Confidence assured.
Of course if you don't have the coding to back this up, say check ins are only occurring every couple of days then this won't work for you. In larger, or mature, products you have code being checked in all the time, and that's where the gain is. You need to determine the best output for your team.
So before worrying about whether or not you are following a specific methodology get some basics in place first, Nightly Builds is one of the most important.
No comments:
Post a Comment