Five Reasons to Use a Staging Server

If you are interested in avoiding common and difficult to reverse issues when deploying new or updated software to a production environment, use a staging server – at a minimum. Your staging server should be configured as closely as possible to the production server. With virtualization, the process of cloning a server becomes a relatively trivial task.

A staging server provides a safe vehicle to “discover” and prevent commonly overlooked deployment issues:

1. missing assembly references or resources. This is a frequent occurrence if you use third party tools like Infragistics, Telerik, or another. When you install the development tools, they often add the assemblies to the GAC on your development box and scripts and images to “special” virtual directories. If you blindly deploy an application to production without making sure you have the assemblies either in the GAC or referenced properly in your application, it can frequently lead to run time errors and the yellow screen of death. Even items you might think are part of the .Net Framework that are pre-loaded in your Visual Studio toolbox, such as the ReportViewer control require the installation of a ReportViewer Redistributable executable.
2. dependencies on physical hardware. Depending on how the application is configured, your application may unwittingly be relying on a writeable F drive where on the server the F drive may not exist or may be a CD-ROM drive. Or require a 64 bit processor on a 32 bit server. It is better to catch these issues before deploying to production.
3. require elevated file system permissions. If your application is writing XML files or storing media, the application upload path will require Write permissions for the accessing account. Permissions requirements should be part of the installation/upgrade process, not left to post installation troubleshooting.
4. require least privileges on database permissions. You may be using the sa account (not recommended)on your development box, but your production DBA and/or company policies won’t appreciate that in production. This is an opportunity to make sure your application is running under an account or group with the least privileges necessary to run the application and make sure if your installation process is dropping/re-adding stored procedures or tables, you are also adding the appropriate grant select, insert, update, delete, execute, bulk insert, or truncate permissions to avoid unexpected SQL errors.
5. require configuration changes to interface with other services, such as IIS version differences, SMTP, or Message Queues. On your development box, for simplicity, you might be using a local IIS SMTP service, or file system implementation to test emailing functionality, but if the production environment only allows mail to relay through a Microsoft Exchange endpoint, you have some additional configuration to do. Making sure all the appropriate accounts are understood and configured properly often takes coordination with other IT specialists. They’ll appreciate it if you coordinate it at their convenience on a staging server instead of elevating the issue to a production emergency.

This isn’t intended to be an all inclusive list, but hopefully if you are not using one today, it will inspire you to consider using one in the future. Prevention is the best medicine for software implementation.

The staging process provides an opportunity to perfect the installation process for a problem free installation. Additionally, having the installation process consolidated to a single series of installation and configurations steps in a single package with all the necessary files and scripts can simplify recreating software versions for disaster recovery purposes or for replicating to additional installation deployments, such as for different customers or at a different site.

Photo credit: Anirudh Koul / CC BY 2.0