Recommendations and workflow for maintaining a test instance of Execute
To get the maximum value from the test environment, it is important that the test environment is a close replica of the production environment (configuration, data, and integrations).
The following document describes some workflows around an Execute testing environment and how to configure and maintain it for maximum usefulness.
The Test Server
Some clients choose to maintain a completely separate testing environment where Execute Test & Prod are deployed onto isolated virtual machines. This approach gives the best isolation between the environments. It’s also perfectly acceptable to install both Execute Test & Prod to the same server, with each configured to run on a separate set of TCP ports. Generally, things being tested by an Execute test environment are constrained within an environment and do not affect other environments installed on the same machine. An advantage of Test and Prod services being installed to a single computer is that they can share the same DNS and SSL configuration.
When installing the Execute Service to virtual machines, it is important to ensure that these virtual machines do not share a Windows SID (caused by cloning the virtual machine without running SysPrep). Failure to ensure that Executevirtual machines have unique SIDs will cause problems when licensing Execute.
For more information see https://support.microsoft.com/en-us/help/314828/the-microsoft-policy-for-disk-duplication-of-windows-installations.
Configuration
Execute uses many auxiliary configuration files in the service’s config and plugins folders. These files enable and configure optional functionality including notifications and integration with outside systems. Some configuration files contain database connection strings or service addresses to other production services. Therefore, it is not safe to copy configuration files from production to test in an automated / bulk fashion. For example, if a configuration file that defines integration with an accounting system is copied from production to test, it can cause testing data to be pushed into the production accounting system.
It is not safe to copy configuration files from production to test in an automated / bulk fashion
The workflow should always be to build and test configuration file changes in the test environment and, after testing, manually migrate those specific changes to the production environment.
Environment Label
To avoid confusion for users (and to prevent users from treating a production environment as a test environment) it is highly recommended that environments be labeled by adding an environmentLabel line to the “config\user.config” file as below:
The environment label will appear on the login screen:
And in the title bar when logged in:
Email Notifications
Test environments should never be configured to send mail (the exception being when email is specifically being tested). While outgoing email from a test environment is marked in the email subject, unexpected notifications from a test environment can still be quite alarming to users. Setting the “Suppress All Mail Notifications” setting to “Yes” will prevent an environment from sending email. This setting is saved in the database, so it’s often not appropriate for use in test environments that are routinely refreshed from production - where that setting is turned off. Unless part of the refreshing process automatically re-enables the email suppression setting, it’s likely email will be inadvertently turned on at some point. To guarantee that an Execute test environment never sends email, it’s best to ensure that the smtp.config file in the config folder has an empty smtpServer property: Prod: <smtpServer>mail.example.com</smtpServer> Test: <smtpServer />
Because this configuration file should never be copied from production to test, this setting should never be overwritten and it should prevent accidental emails.
Integration Configuration
As mentioned previously, some of configuration files are build integrations between Execute and 3rd party systems. These configuration files often contain database connection strings, URLs, network paths, etc which point to production resources. It is extremely important to be careful while copying configuration files from production to test so that your test environment does not reference an external production service. To prevent test data from being spread into production systems, test environment should always be configured to use test instances of any external systems it integrates with. A possible exception to this rule is the case where Execute only reads from the 3rd party system.
Keeping the Test Database Current
It’s important to keep data in the Execute test environment as similar to production as possible. This is usually done by automating a monthly or weekly process to refresh your test database with a new copy of production.
The following is a typical workflow for this refresh process:
- Stop the Execute Test service.
- Drop the Execute Test Database. (ie. AFE_TEST)
- Copy the Production Database to the Test Database (ie. AFE_PROD to AFE_TEST)
- Often it is best to do this step by restoring your database level backup of prod into the test database. This has the benefit of also ensuring that your database backups from production work.
- It is not required that the production service be stopped to copy/backup the database.
- Optional: Run SQL scripts to reset user passwords and turn off Windows Authentication to allow testers to log in and out as different users more easily.
- Start the Execute Test service.
In cases where Execute Test integrates with other 3rd party systems it may be required that all test environments are refreshed together to ensure a consistent state across interconnected systems.
Testing Major Upgrades
In cases where an upgrade to a new major version of Execute is expected to span multiple weeks or months, it is recommended that clients set up an additional test environment for the new version while keeping any existing test environments for day-to-day testing.
This additional test environment avoids situations where changes can’t be effectively tested for lack of a test environment of the same version as production.