SNAP stands for Shiny New Automation Process. It was designed by the NetDocs (also known as Xdocs or InfoPath) team to control the execution of large complex jobs on a network of computers. This specific build tool has been around Microsoft for the past five years, and some of the tool’s predecessors have roots that go even further back. With some minor configuration changes, the system has also been used successfully for tasks such as managing source code check-ins, performing daily product builds, running test automation suites, and validating automation tests.

Although you can use the SNAP system in a variety of ways, the emphasis in this chapter is on managing source code check-ins and using the SNAP system as an integration build tool. This is the most common way that SNAP is used at Microsoft, and it has the highest interest of the customers with whom I have spoken.

As I discussed in the previous chapter, changes to source code need to be atomic. What this means is that check-ins into the mainline source tree should be reverse integrated (RI) as a whole or not at all. This ensures that any developer who makes a change will have all or none of the changes applied together. If conflicts exist among the sources being checked in and the currently checked-in sources, you must resolve them before the changes will be accepted.

What the SNAP system does is add many additional checks into the atomic operation of checking in source code. It ensures that code check-ins are held to a certain standard and that they do not break the mainline build or create a merging nightmare. Whereas most source code control tools require only that conflicting changes in the text of the source are fixed, SNAP permits an arbitrary amount of additional processing involving almost as many machines and discrete steps as you like.

You might be thinking that this would also be a great tool for Extreme Programming—see Appendix B, “Extreme Programming,” for an overview of Extreme Programming—and I would agree. Note, though, that this is only a tool. There is a lot more to Extreme Programming than an automated check-in and build system.

You might want to implement a SNAP build in two places:

Alternatively, you can implement a SNAP build in both places. The implementation depends on the complexity of your build process and product.

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.

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.

The following information will give you an idea of a typical SNAP hardware configuration that you need to budget for if you plan to create or purchase this system.

Following is the SNAP build machine configuration:

And here is the test machine configuration:

After a SNAP system is set up, you should not need to configure one of these machines from scratch unless you have a catastrophic failure that requires rebuilding the unit.

The SNAP administrators are responsible for keeping all the SNAP machines current with all hotfixes, patches, and critical updates. When indications of such updates are available, you need to check each machine for new updates via the Windows Update site. The biggest administration required is monitoring the test machines periodically to ensure that they are all being reset and updated correctly.

SNAP is a queue-based check-in system. A developer makes a submission to the SNAP system either via the command line or through a Web UI instead of checking his files directly into the mainline source code tree. The changes that the developer submits are then copied to a SNAP server, and a check-in is added to a queue in the lab. Inside the lab, a control process pulls check-ins off the queue and builds and tests them one at a time. The test team provides the tests. The system is designed to rerun parts of a check-in, ignore failures, abort a check-in, or allow modification of files in a check-in if needed.

If a developer’s check-in breaks the build or something else goes wrong with the check-in, the system sends an e-mail to the developer and the entire team letting them know where things have failed. The developer then must figure out why his job was aborted and resubmit it.

Keeping your development personnel productive and happy with a checkin system requires constant monitoring of the process. The key to the success of the SNAP system is constant monitoring, or babysitting. Nothing upsets a development team more than a system that does not work and no one available or with the resources available to fix it.

Don’t try to run the SNAP system unattended. You need properly trained people to debug and own any problems with the system. This is usually someone from the build team, but it does not have to be. If you can make your build and testing processes highly reliable, you might find that you can go extended periods without close supervision. Either way, you need resources assigned to attending and maintaining the system.

It is worth noting here that without knowing the details of your lab process, you will not be able to properly manage a SNAP system. In other words, if your IT department owns all the hardware or you do not have a properly equipped lab, it will be difficult to manage a SNAP system because you will not have direct access to the machines or be able to modify the hardware configuration if needed.

The primary measure of success of the SNAP system is throughput—the number of check-ins processed over a given period. The demand on a check-in system fluctuates during the course of the development cycle. For example, just after you finish a major milestone, the demand on the system drops significantly. Conversely, in the closing weeks of the next milestone, demand on the system rises, peaking around the milestone date.

To figure out an average check-in time with a SNAP system, take the length of your longest build and add to it the length of the longest test. Add the time it takes to set up the test machines. Then add a few minutes here and there to account for the time needed to perform bookkeeping and process the actual SNAP submit statement. You now have the expected length of a check-in, assuming that you buy enough hardware to run as much as you can in parallel and you have decided to integrate testing into your SNAP process.

From the length of a check-in, you know the number of check-ins per day that you can process. At peak demand periods, it seemed like our developers needed to be able to process a check-in every other day or so. During off-peak intervals, we were seeing a rate closer to once a week.

Again, use these guidelines in conjunction with any data that you have on your current check-in process. In most source code control systems, you can easily discover the number of change lists that have been submitted to any given branch.

This data will help you determine the schedule of your project and how you can improve your build process by either adding more hardware or rearchitecting some processes.

SNAP works best when you can divide processes into small, independent pieces and run them in parallel. Because a product build must often be able to be run on a single developer’s machine, it is difficult to parallelize the build. But testing can generally be made to distribute reasonably well.

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.