Your Dynamics GP system is a business-critical software application and care should be taken to ensure no changes are made without vetting them in a test environment. A test environment can be either a “test system” or a “test database”.
A Test System is a stand-alone GP test environment consisting of a computer with SQL Server installed, restored databases from the live environment, and a GP client configured exactly the same as it is in the live environment. Often a high-quality workstation is sufficient for testing purposes, avoiding the costs associated with duplicate server hardware.
A “test database” can be the sample company, Fabrikam, or a restored back-up of your live database into a test database.
A Test System is the more safe way to test new software and configuration changes. Being completely isolated from your live environment there is no risk that any change could have adverse consequences to you day-to-day activities in GP.
A Test Database isolates changes to the company database. This is often sufficient for testing configuration (setup) changes, but has some drawbacks when testing new modules/software. Among the disadvantages of this approach are:
- It does not control changes to the DYNAMICS database. New software may require system-level data storage, and/or other changes inside the DYNAMCIS database.
- If the GP client used for testing is also used to access the live database, the presence of new software on the client could affect the live company when the client is used to log-in to other databases.
- It does not control changes to shared forms and reports dictionaries, which are accessed by all companies. If the new software/change affects the forms and reports dictionaries it could cause problems for users in the live company.
- In a Citrix or Terminal Server environment there might be only one client, so a change to that client could affect all users.
Validate ALL changes to your GP environment before deploying them in live. Any change, from changing a setup option for an existing module, to installing new software, should be tested before being done in live.
Keep a log of changes. Note the date on which changes were made, who made the changes, and the reason for the changes.
Have a recovery plan. There are different types of failure and thought should be given to recovery in different scenarios. For example:
- In the event of total system failure, how do you recover? This plan should be documented. Address failure during different times of the day. Failure during peak business hours might be addressed differently than failure after hours.
- In the event a configuration change has unintended consequences, how do you recover?
- In the event new software causes a problem, how do you recover? Our Installation Guide is designed to provide a high level of failure tolerance, but each environment is different, so careful attention must be paid to the unique requirements of your environment.