How SNAP Works

SNAP uses a system of networked machines, usually in a lab, to verify that a developer's check-in will build with the current set of sources before allowing the changes to be checked into the mainline or VBL source code tree.

Note

Remember in Chapter 3, "Daily, Not Nightly, Builds," when I discussed monitoring all check-ins? SNAP is a perfect tool to do that for you, but make sure you don't skip one important step: The WAR team must approve check-ins before checking the code into the mainline source tree.

The core of the SNAP system is in two SQL Server databases. The first, called the SNAP database, shares information but logically describes two parts: a set of queues and a set of machine daemons. This database is designed to be unique throughout your lab. The second, called the Tuple database, controls the actual operations of a check-in (or any other job).

Figure 6.1 illustrates in schematic form the components of a SNAP system and how they communicate. In this diagram, the drum-shaped objects are databases. Square-cornered boxes are HTML pages that use dynamic HTML and a combination of remote scripting and .NET technologies to query their corresponding databases.

Figure 6.1. SNAP.