Producing Pristine Environments

In TestEnvironments, Pristine Environments are described: Un-installation is never perfect. Installing, then un-installing, can leave side effects that further installations can (accidentally) depend on.

Here are some methods for producing pristine environments for various operating systems:

EMF spike.

Microsoft Windows and OS/2: Use Ghost <http://www.ghostsoft.com> to restore a clean operating system installation from a disk image.

The people who produce PartitionMagic also make a drive image product that works well. The one thing we found we couldn't do was to restore a disk image to multiple, nominally identical, machines because (of course) they weren't identical. --SteveFreeman

RollingMigrations? maintains near-pristine production systems by continuously migrating projects to new, clean systems in a SlidingWindow? fashion. Other SystemsAdministrationPractices support RollingMigrations? and are even more regularly applied to test and development systems.

This is nice for systems that, with their OS, fit entirely on one hard disk of one computer. Standalone PC software? You're all set. Something more complicated? Maybe not.

An "environment" can include a Web server, a database server, a router, a PBX ... in fact, that, plus some embedded (downloadable) software in an access switch, is the environment for the product I'm currently working on. Even a simple client/server system may require an environment consisting of two computers. --PaulChisholm

Use virtualization software like Microsoft Virtual Server 2005. It has the ability to save and restore a snapshot of an entire virtual PC. Run multiple virtual PCs with a virtual network between them to emulate a multi-tier or multi-server application.

Why bother producing pristine environments for testing? When your code is in production, your users won't have them. It seems to me that we want to test the code on environments that are really gunky. --JohnFarrell

This would be true unless reproducability is important to testing.

Exactly. You want to be able to test with "gunky" environments but you need to be able to reproduce the gunky environments at will in order to have consistent test results. --JamesCrawford

The "gunk" is the problem: My development machine has many tools and up-to-date releases of software that are not currently present on the client/delivery/production machines. Like, I have all the latest web development ActiveX stuff, but my end users don't (unless I include it in my install program and give it to them).

Therefore, it's important to start with a minimally configured "clean" machine to ensure that my installation process puts in everything my program needs. -- JeffGrigg

See also VoodooBug, VoodooFix

I get a lot that a build works locally but doesn't work on the automated build. The automated build is a pristine environment. Developers usually have extra search paths, already build libraries, etc around that can make their builds work.