Summary

The goal of using the SNAP system is a stable, clean main source code tree from which you can produce a green build (one that has no flaws in tested functionality) at any time. Ensuring that stability requires carefully screening source code check-ins to prevent bad code from entering the system.

In principle, all developers should build and test their changes before checking them in, without a process in the lab. However, this is impractical. Building all the pieces of some big projects (both debug and release) and running the full check-in test suite for both builds might require several hours of development time in their office. There would also be a lot of time spent diagnosing intermittent test failures only to determine that they were known bugs. The SNAP process can minimize this problem and help developers be more productive.

This chapter on the SNAP system tools assumes that it is used to process check-ins. The SNAP system can also process many other kinds of tasks, such as daily builds, test automation, and validation, as mentioned at the beginning of this chapter. Therefore, if you can develop your own SNAP system, you will get an enormous amount of benefits from it. If you are not able to develop your own and will purchase a SNAP tool, this chapter provided you with a little more insight and knowledge of some of the advantages and disadvantages of such a system.