Many of the systems our clients work with could rightly be considered business critical systems.  Whether its Design Automation (DA) tools, a PLM/PDM system, a custom application, or a tool for electronic process automation Razorleaf’s clients would be hard-pressed to efficiently complete their day’s activities if the system was down or not operating as it should.  There are a number of items that should be considered when making a change to one of these systems including ensuring proper documentation, training, system design, and testing.  One of the most overlooked best practices to ensure success is having a staging area where applications can be rigorously developed, tested, and deployed.

Why are separate environments needed?  The most basic is answer is this – you should never make changes to a working production environment without first ensuring the changes are correct and well-tested.  Of course if you don’t have a separate staging environment it is impossible to follow this simple rule.  Even seemingly small changes can lead to a bug or a regression.  Ask yourself, “If I made this proposed change and the system became totally unusable for all my users during normal business hours would that be OK?”  If you hesitate in your answer at all, then don’t even think about making the change without first putting it through its paces in outside the production environment.

A development environment is where programmers live.  This environment will typically have development tools like Visual Studio.NET installed.  Other development tools for logging, performance monitoring and debugging may also be present.  This environment can typically be refreshed very easily (i.e. via a Virtual Machine snapshot or a disk partition image) and may be loosely controlled when it comes to system access to allow the programmers to make registry, database and network changes easily.

A test environment is very different from the development environment. Instead of containing special tools and software or being configured with special permissions or access, the test environment is identical to your production environment.  This environment is closely controlled so that software versions, permissions and configuration options match the production environment.  All testing takes place in this environment.  A test environment will serve multiple audiences.  Programmers will use it to test changes and enhancements to custom applications.  Systems administrators will use it to test new versions of software or software patches.  End users will use it do to unit testing and verify an application meets their specific business needs.

We hope you have noticed a subtle point throughout this article; we have been very careful to use the term “environment” versus “computer” or “machine”.  These environments will often consist of multiple computers.  Is your application a client/server application?  If so, then your environments need to be client/server environments.  Networks add a whole new set of potential issues, with performance and access/permissions being two of the most obvious.  Something that works on the server will not necessarily work on the client when network latency and permissions are added to the mix.

Some may wonder if it is overkill to have multiple environments and multiple physical or virtual servers.  The answer depends, on whether you can afford for all of your users to be down during business hours because a change did not work as planned.  If you have no problem with that scenario then it may be overkill.  However, for the systems that we talked about at the outset, most people would probably agree that downtime for business critical systems has a significant cost to the business.