Create a scalable test environment

New software products are appearing on the market all the time, and one of them may be just the thing your company needs to increase productivity and reduce costs. But deploying new software can also have all sorts of pitfalls. What if it doesn't work the way you expected, or its features aren’t really what your users need to get their work done? What if it causes some unanticipated incompatibility with your other programs, or even crashes the operating system?

Even if you already have the applications you need in place and rarely add new ones, it’s likely that you’re still deploying new software all the time -- in the form of operating system and application updates and security patches. Unfortunately, these can cause problems, too. It’s not uncommon for the "fixes" to break things.

The prudent thing to do is to test any new software, including patches, before installing it on your production network. But that involves creating a test environment that emulates your "real" network as closely as possible. Whether your company is small or large, that can strain your budget. But there are ways to build a test environment, even if your company is small and doesn’t have a lot of money, without breaking the bank, and ways to grow that test environment as your business grows. This week, we’ll take a look at some tips for creating a scalable lab for testing software instead of risking everything by rolling it out "blind."

Planning your test lab

The first step in creating your test environment is to determine the scope of the testing that you intend to do there. If your goal is only to find out whether a particular software solution is compatible with your current operating systems and applications, you’ll need a less complex test environment than if you also want to test things like network infrastructure design changes and software suitability for particular users.

Either way, the test network should be completely separate from your business LAN. You don’t want any of the experimental work you do there to affect your productivity network. You’ll want to set up a completely different subnet for the test network and ensure that it’s not physically connected to the LAN.

In designing the test lab, you’ll need to gather information about your productivity network and then determine which components need to be replicated on the test network. You don’t necessarily have to replicate every element of the productivity network. For example, you might have a SharePoint Portal Server on your productivity network. If the software you plan to test doesn’t interoperate with and the computers that will be running the new software don’t communicate with the SharePoint server, there is no need to include one on the test network.

As you design your test lab, it's important to document it so that you know exactly what machines, devices, connection types, etc. make up the environment.

Building the test environment

Once you’ve decided what servers and clients will be needed on your test network, next you need to decide how many physical machines you need for the test lab. You can save money by creating multiple servers on one physical machine, using virtualization software such as Microsoft Virtual PC/Virtual Server or VMWare.

This is an especially scalable solution because it allows you to spend less money on hardware, and you can add additional virtual servers by upgrading disk space and RAM, instead of buying complete machines to emulate each new server that you add to your productivity network.

You can install different operating systems on separate virtual machines on the same physical machine, to emulate a cross-platform environment. For instance, you can install UNIX or Linux on some virtual machines and Windows on others. You can even install your clients and servers all on the same physical computer, in separate VMs. Each virtual machine has its own IP address and they can all communicate with each other on the test network, as well as communicating with other physical machines on the test network.

When your business is small, every penny counts. Using virtualization software not only saves you money when you purchase hardware; it also saves money on power usage since you’re running far fewer actual computers.

You may also be able to save money on software by obtaining trial (evaluation) versions for testing. This way, you can determine whether the software will work for you without having to purchase it first.

Be sure you don’t neglect licensing issues when you set up your test lab.

Using the test environment

You should use the test bed to try out any major changes that you propose to make to the production network. Examples include:

· Upgrading operating systems

· Installing new applications

· Deploying service packs and hot fixes

· Deploying security updates and patches

· Major configuration changes

It’s not usually necessary to test simple configuration changes or routine maintenance tasks.

You’ll want to consider the length of time that you should run the test systems with the changes before considering the changes safe and deploying them on the production network. You should definitely run new operating systems or applications for a minimum of one to two weeks, and be sure to perform tasks on the test systems that emulate normal user activity.

It may be a good idea to bring in users who work with the software on a daily basis and have them test the new software, as they may perform tasks of which network administrators are not aware.

Just as with your production environment, you should clearly define support responsibilities for the test environment.

Summary

By using virtualization software to install multiple instances of the same or different operating systems on the same physical machine, you can create a software testing environment that is cost effective and scalable. As your network grows, you can add additional physical machines to grow the test environment so that it always simulates your production network and makes it possible to avoid costly mistakes in deploying new operating systems, applications and patches or making major configuration changes to the software or network infrastructure.