- Your team is implementing unit tests. Unit tests can run as part of the nightly build and alert developers on errors.
- Developer instances may not have access to full data sets or production data. New tests can be built and automated for the nightly build to test and report on changes to the code (features) against a more complete data set.
- You have a QA member on the team that will perform functional and regression tests on the nightly builds.
- You want your stakeholders to review and comment on checked in features.
- You have other teams that perform other tests and validation. Maybe load testing, browser testing, or builds for multiple OS’s.
- Your building a SOA set of shared services and want to run tests against older versions.
- You have multiple features being developed for a single release and may need to role back to a stable point if implementing one feature is dragging the time line. Let’s call this lazy branching.
These are all good examples, but I still maintain that they’re not necessarily the first thing a new development team should prioritize. Implement your nightly or automatic build when you find a customer (QA, stakeholder), a process (unit testing, load testing) or to address an issue.






















Leave a Reply