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.
Pages
About the author
Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:
- Manage Your Job Search
- Hiring Geeks That Fit
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management
- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.
