Â©2006 Johanna Rothman. This article previously appeared on stickyminds.com.
During a recent in-house project management class, I suggested that the project teams move from weekly builds to nightly builds, preferably with an automated smoke test as a technique to increase the pace of the project. â€œWe canâ€™t do that,â€ one of the project managers said. â€œOur testers canâ€™t keep up.â€ Why do your testers need to keep up? Nightly (or hourly) builds arenâ€™t for the testers – though they can take advantage of newer builds- but for the developers.
Developers receive timely and frequent feedback
With staged integrationÂ -Â building weekly or less oftenÂ -Â developers receive feedback about their work at least a week after they check it in (sometimes a month or more, in my experience). With nightly builds, developers receive feedback the next day on the previous dayâ€™s work, which is a hallmark of agile development.
With nightly builds, if a developer has a bad development day, that developer receives feedback the next day, wasting only one dayâ€™s worth of work. With less frequent builds, developers receive feedback days or sometimes weeks after theyâ€™ve finished their work. Itâ€™s too easy for developers to get stuck with incomplete or wrong thinking and not realize it until weeks have passed, making the project late and adding to the needed rework.
One of my clients can only build their system about once a month. They need a full week to resolve the compile circularities, and then another couple of weeks to find all the people who broke the build to fix their problems, resume or restart the compiles, and finally complete the build process. Itâ€™s possible for a developer there to have to change something checked in two or three months ago, because problems with that code didnâ€™t appear until a build or two later when someone else checked in a complete piece of work.
Staged integration, in which developers wait until an entire piece is done to check in the whole darn thing, helps each developer complete a chunk of work, but slows the progress of a project. Hereâ€™s why: A developer starts developing in a private sandbox, and every day pulls down the latest changes from the mainline. The developer checks for differences and integrates any found into the code under development. With any luck, no other developer is working in the same area. But if there is someone else working in that area, the developer has a choice to make: does she take the updated code or continue to work in solitude until her piece is complete?
Many developers wait to integrate their code until it is structurally complete and cohesive. But the longer it takes for that developer to complete the code, the more the mainline is changing. And the longer the developer waits to integrate that piece of code with the mainline, the more work the developer has to complete for integration and the longer the developer has to wait to receive feedback from the build process.
Contrast staged integration with continuous integration: where small pieces are integrated every day and the system is built every night. Every day the developer brings down the new changes into the private sandbox, makes changes to the code, saves the changes, and updates the mainline. Not only does the developer receive feedback on the code via the build process, but also other developers can see whatâ€™s changing in that area.If multiple developers are changing code in exactly the same area, they have to talk to each other to make sure they donâ€™t step on each otherâ€™s code (a practice that helps any project). But chances are good that even if developers are working in the same set of files, theyâ€™re not working in precisely the same areas of the files. Most configuration management systems will automatically merge the changes without problems.
When developers integrate small pieces every day, they are less likely to propagate mistakes for weeks. Instead, because changes are available to everyone using the updated sources and builds, the developers receive feedback within a day. If something is wrong, they only have to look at yesterdayâ€™s changes, not a weekâ€™s or monthâ€™s worth of work.
Testers receive the option of which builds to take
While continuous integration (nightly builds at minimum), solves the problem of ensuring developers receive feedback about their changes, testers might feel left out in the cold. In fact, one tester told me, â€œI canâ€™t take every nightâ€™s build, my regression tests alone take three days to run.â€Testers have a choice. They donâ€™t have to fully test every nightly build. Maybe theyâ€™ll use the weekly build on which to run regression tests. Maybe theyâ€™ll choose to do some exploratory testing on a nightly build in a particular area. Maybe theyâ€™ll verify fixes in a different area for a particular build. Testers are responsible for assessing the risky areas of the product and deciding how to test that area in the current build.
Itâ€™s not reasonable to expect testers to fully test every build every day. It is reasonable to discuss with testers what their testing strategy will be during the different times of development, so you know the testers are making progress and the developers can receive the testersâ€™ invaluable feedback.
Nightly Builds Might Not Be for Everyone
I have yet to encounter a project where someone canâ€™t use nightly builds, but, then again, I havenâ€™t encountered all projects. Itâ€™s possible that your particular circumstance prevents the use of nightly builds. Certainly, if the testers are the only people on the project who use the build, nightly builds may be building too often. But increasing the frequency of your projectâ€™s builds is a quick step toward helping the developers see where theyâ€™re going, and that helps the project make forward progress.