I Depending on your system, needs, and resources, it can be advantageous to set up a development or testing environment separate from your production knowledgebase (KB). With a dedicated development space, complex or experimental buildout can be done without locking important production tables or records, and without risk to essential business functions in the production KB. When changes in the development environment are complete and have been tested, they can be moved to the production environment, either using Pushing Changes to Production or by rebuilding manually.
In either case, if changes are made directly in production, either to fix immediate issues or to add simple functionality, it is important to refresh all development or testing KBs with these changes before using them for new buildout.
This page offers recommendations and tips for successful management of multiple environments. For more information about maintaining the environments using sync functionality, see Pushing Changes to Production.
For information on how to make a copy of your production KB, see Transferring Knowledgebases Across Servers.
You must have access to the admin console in order to copy a KB and to perform some of the steps discussed below. |
Working with multiple environments introduces the risk of users accidentally making changes to the wrong system. To help prevent these mistakes, it is important to make it obvious which environment is open. There are two common solutions, sometimes used together.
Set up a different Look and Feel scheme in each KB. The schemes should be very different, so the users can recognize each scheme as belonging to its environment. For example, you might use a company color palate in the production KB, but a completely different set of colors in the other KB.
Add a message at the top of the page, such as THIS IS THE TEST KB.
| To edit the page headers, first make sure they're enabled. Go to Setup > System > Manage Global Variables and find the Header Text global variable. If it appears on the Customized Variable tab, then it is ready to use. If not, go to the Variables with Default Values tab and click the Edit icon to add the header. Don't add any text here; just save the variable without making changes. |
You can add a Test KB message in several places. We generally recommend using the page header, which doesn't take up extra vertical space.
Make sure the end result gives you a development or test environment that looks very different from the production environment. You typically don't want to use custom headings like this in the production system, so people may not notice they are in the production system unless they develop a recognition for the distinct look of the other environments.
There are several configurations and/or integrations that must be kept distinct between the test and the production systems.
If you use DocuSign, you must disconnect the production DocuSign account from the development or test environment immediately after creating it. You can set up a development DocuSign account afterward if needed, and then link the development KB to that dev account.
These steps should be taken each time you refresh content from production to other environments by copying the KB.
Open the development or test environment.
| Do not follow these steps in the production environment. |
First, locate and collect the server and account information for the development account you want to connect. This is typically on a different DocuSign server than the production account.
Open the development or test environment.
| Do not follow these steps in the production environment. |
On the DocuSign site, log in to the production DocuSign account and go to Admin > Connect. Make sure you see an active connection.
If you don't see an active connection, you need to reset it:
If there are scheduled imports or other time-based rules that run integrations or syncs with other systems, such as Salesforce, you might want to disable all time-based rules until you have time to review them and make any necessary modifications. To test scheduled imports on a test system, you need to have a separate folder for the files so you don't take files from the production system. Likewise, if you sync with any external systems, you need a sandbox external system on the other end to test those syncs. For example, if you sync with Salesforce and you want to test that sync from a test system, you need a test Salesforce sandbox to sync with.
If you use SSO with SAML, you usually need to set up a secondary SAML endpoint, and a separate SAML configuration for each system. If you have a development LDAP server, you need to configure that as well. In both cases, you likely need a separate login page for the development instance.
If your system is using inbound email accounts, you need to create separate inbound accounts for each environment, so the development environment does not "steal" the inbound email for the production server. It is best to create a separate test account for each production inbound account, and then to set all accounts up in the production system, but disable the test accounts there. That way, each time you copy production to refresh the dev environment, you just need to disable the production accounts and enable the test ones.
To disable or enable an inbound email account:
If you are concerned about users being confused about which system is sending them email, you might want to tag the test emails. There are a couple of ways to do this.
If most of your emails appear to come from the default outbound email address, you can simply change that address to one with the word TEST prominently featured. To do this, go to Setup > Email and SMS > Email Server Settings. This is best practice in any case.
If you want even more differentiation between production and test emails, you can set up a field variable and use it in all email templates to insert a signifying word, such as TEST, in front of the subject line of emails sent by the test system. This is more involved to set up.
When an email is sent from the production system, the variable is blank. When you send email from the dev system, if you have changed the value to TEST, that value is displayed at the front of the subject line.
In the test system, you can prevent inadvertently spamming users with test emails by mass editing all user records to remove email addresses. Simply leave the email addresses of the users who are involved in the testing or development. This prevents any scheduled reports, escalation rules, or other automated communications from bothering the rest of the users.
Of course, you can also just turn off all outbound email from the dev server, but that prevents any actual testing of outbound emails.
With multiple environments, at the beginning of each development or testing cycle, if any changes have been made directly in the production system, the dev system often needs to be refreshed with those changes. This is usually done by just copying the production system and importing it onto the test system as a new test KB. Alternatively, sync can be used to transfer just the configuration changes, but this generally takes more time, and is only appropriate if you need to cleanse data from the dev system and deletion would be more time consuming.
To refresh other environments successfully and avoid issues and troubleshooting, it is best to create a checklist specifically to prepare for and perform a successful refresh from production.
The checklist depends on your system and configurations, so it is strongly recommended you modify this example checklist to suit your needs.
Before Refresh
After Refresh
|