Why you shouldn't develop on your production instance

[Dawn Jurek]

Anyone who has ever administered a web site or a ServiceNow instance can probably relate to this dilemma. You need to make a tiny change, such as adding a field to a form, or activating a plugin, and you're really pressed for time. Why not just quickly make the change on your production, or PROD, instance? What could happen; it's a minor change, right? In this third installment of our best practices series, we look at why you should never develop in production, and what you should do before making any changes to PROD.

Why you should never develop in a production instance

Sometimes it may be tempting to knock out small changes in PROD, but changes that seem minor can have unexpected and far-reaching effects.

For example, when you activate the Timeline Visualization plugin, Project Management V3 is automatically activated as a dependency, which could produce unwanted results. Before activating any plugin, make sure you understand which additional plugins get activated automatically, and which features they affect. These are described in the product documentation, like the example shown below.

Development best practice

Perform all development in a sub-PRODuction instance and thoroughly test everything that's affected before deploying to PRODuction. This includes even small changes, such as adding a field to a form, or activating a plugin, updating an access control list (ACL) rule, or tweaking a client script.

Before making ANY change to your PROD instance:

• Make the change in a sub-PROD instance.
• Make sure you understand how the change may affect downstream features, functions, and data.
• Use small update sets that can be backed out more easily than a large one.
• Thoroughly test the changed feature and any dependent features or functions.
• Ideally, have other stakeholders assist with testing because they follow their normal workflow, which an admin may not be familiar with. This helps identify any issues that aren't evident to an admin user but may show up for users with other roles (such as itil). If other stakeholders can't help with testing, use impersonation.
• Always have a back-out plan, which includes backing up all records that will be affected by the change.

Leave your PROD pristine, and take all your tweaking and testing offline to your sub-PROD instance.

--

Behind the scenes here at ServiceNow, the Knowledge Management team works closely with subject matter experts to disseminate critical information to our customers. We've found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise.

See Annotate scripts and customizations with comments for the first installment on script comments.

See Limit the Number of Users with the Admin Role for the second installment on user roles.

See Where to avoid linking to a reference field when configuring a list for the third installment on list configuration.

To access all of the blog posts in this series, search for "nowsupport best practices series."