Development and Test Environments

Ideally, each site would have a Development, Test, and Production Environment. Although we don't see it often, ideally each environment would be isolated on its own subnet or Virtual Machine LANs so that most servers could not connect to each other. The one exception is the Process Historian, which may be used as the source historian for all three environments simultaneously.

Development

A Development environment should be created if the site anticipates a lot of new development or new configuration work being anticipated. This could be considered a trial & error until success environment. Some might refer to it as a "sandbox" where there is a fair amount of freedom for experimentation or simulated training. Ideally, new development or configuration is taken to a stage where there is confidence that it "should work" and has reached the testing stage for the Production environment. Regarding infrastructure, it is important that most applications that are likely to be configured or further developed be installed. The server topology, however, does not have to match the Production environment. Where there are cost savings available due to merging servers or realistically reducing CPU/RAM "horsepower," these should be taken advantage of.

Test

A Test environment is required for most MES environments. It should mimic the Production infrastructure as much as possible: Server Topology, Server configuration (Operating System, CPUs, RAM), Server application installation base (Application Server, SQL Server, Visualization Server, Process Historian). Often effectively mimicking the OPC layer is not feasible or possible so this is often not part of the testing environment. A workstation to test client installs will also be required. If workstations are deployed by using something similar to a Citrix environment, then a Test Citrix server may also be required.
The Test environment is used for:

1. Testing new Operating System updates

2. Testing new application hotfixes or SIMS

3. Testing newly developed or created configurations (ideally developed/created first in the development environment).

4. Training, if a separate training or development environment is not available.

"Refreshing" Dev or Test Environment

1. If there are Operating System or Application upgrades to be performed at the Company's Site they must be performed in all three environments. If all three environments are installed, then they would first be applied to the Development, Test, and Production environments in that order.

2. Refreshing an environment generally means backing up and restoring the SQL production database(s) to the Development and/or Test environment SQL server. This "refresh" involves many steps including some well thought out SQL scripts that convert the server names from the production environment to the server names in the Dev or Test environment as appropriate. It also turns off or deletes any references to the production environment that may allow a "leak" of data to that environment. Typically, a refresh takes around 3 – 4 hours to complete not including the time to backup and restore the database.

3. The site should establish a standard schedule for refreshing the Development and Test environments. A schedule might look like:

   1. Ad Hoc: Ad Hoc requests from various sources. A one-week notice is required to the database team (for backup and restoring DB), to the "refresh MES-IT team" (to allocate resources and to ensure that PA Services are turned off (connections to the database) prior to the database being restored), and to any Support/Project/Training, or Testing teams that may be working in that environment.

   2. Development Environment: Approximately every 6 months (or sooner via ad hoc requests)

   3. Test Environment: Approximately every 3 months (or sooner via ad hoc requests)Disaster