 |
| Photo credits: insidethemagic |
I think, Nightly build is an anti-pattern for Continuous Integration. If you are integrating continuously, then you shouldn't need a nightly build, that would be too discrete :(
If you already have a per-commit continuous integration setup, you shouldn't need the so called nightly build unless there's something bad about the code.
Often times, builds taking >10 minutes are put in the bucket of nightly builds.
Some people put batch processing related tests under such nightly builds. A colleague told me they used nightly build to clean up resources (disk space, recreate the database etc.) on a nightly build - to ensure the apps worked fine on a fresh state.
Under most circumstances, a nighly build means something long running. That in itself can be an indication of poor performance.But what I have seen is, when such nightly builds are broken - they are rarely looked after or cared for. Because, first thing in the morning, who the hell wants to look at that broken nightly build? Even if someone takes a look, since its long running, it might well eat up all morning to actually try/fix/commit changes and see it go green again! Since it takes longer to make the build green, people keep delaying it for later... meaning
it becomes generally acceptable to let the nightly build stay in RED.And once people get used the redness of the nightly build, they start ignoring it, inevitably.
So, here's what I would do:
Avoid nightly builds altogether.
Avoid nightly builds altogether.
Avoid nightly builds altogether.
Otherwise, make one person from the team responsible for the build (rotate people).
