The Only Software Development Lifecycle in ServiceNow

Photo by You X Ventures on Unsplash

Note: This article covers how update sets work and how they should be managed across different ServiceNow environments. This is aimed at newer ServiceNow Admins or those who have lost their way.

Update Sets

As an Admin, you need to start working in “Update Sets” (if you’re not already).

It should go without saying, but don’t make changes directly in production, I see this way too frequently.

Every enhancement belongs in an update set.

Update sets at their very core are just XML files (even something as small as modifying a form.) An update set is a simple data structure where you can capture changes in one ServiceNow instance, and easily move them to another instance. ServiceNow has a built in feature to pull update sets from one instance to another. You can similarly very easily export an XML file of Incidents (or any other data) and import that XML file into another environment.

You should never, for example, be modifying records like ACL’s or scripts in production, even if you know what you’re doing. It’s simply bad practice. If you do, then you’ll have a mismatch between records in production and sub production. So the next time you go and update records in sub production in an update set, you’re just going to writing over the work done in production. See how confusing that can be? The easiest way to not put yourself in that situation is to always use an update set.

It’s important to understand what gets caught in an update set, and what doesn’t. This is a difficult concept for some to grasp, but it’s worth the time.

What’s Captured:

  • All Enhancements (UI Policy, ACL, Business Rule, Client Script, Script Include, UI Page, UI Actions, Widgets, etc.) Any changes to these records are captured in an update set.

What’s Not Captured:

  • Data (As in records created on tables, for example — an incident)
  • Scheduled Jobs

After you create an Update Set, and make it your “current” update set, the ServiceNow platform will now begin tracking all of your customizations.

The “Default” update set should always be on in the background, when you’re not developing. So it’s either the update set you’re currently working from, and when you’re not actively working it, always turn on the “Default” update set.

I worked with a client once and they turned the Default update set off — big mistake.

Once an update set is promoted to another instance, it first needs to be previewed and then committed. The Preview process reviews the configuration for any conflicts. A common conflict that’s seen is one where you have an update in the target instance that wasn’t captured in the source. If you know that your update set is valid, you can either choose to Accept the Remote Update or Reject it. Rejecting it will skip the customization all together.

The “Admin” Role

The ‘admin’ role is every single role in the ServiceNow environment, wrapped into one.

The only users at any given company that deserve this role are the ServiceNow Admins, that are performing actual ServiceNow Development work. IT Management doesn’t need admin either. You will have entitled people in IT that will make the claim that they need the role, but they don’t. Be incredibly careful about allocating this role out.

Users with the admin role have access to every table in the system (unless a scoped application defines that ‘admin’ should not have access. For example: HR Case Management Admins can say, the system “admin” role can or cannot have access to HR Cases. The same goes for all other scoped applications.)

This means they can delete all of your incident records, with a single line of code.

It’s a recipe for disaster and most companies probably have far too many users with “admin”.

Security Admin

The “security_admin” role is similar, but different. Security Admin allows you to update ACL’s and Security Rules and access certain logging tables. All users with “admin” should likely have “security_admin”, unless you have a clear use case to the contrary.

If you’re updating ACL’s, this is a requirement. Also worth mentioning that you need to have security admin, to give security admin.

ServiceNow Environments

Every ServiceNow Team needs at a minimum, 3 ServiceNow instances (You can probably get by with 2, but you’ll run into issues more frequently.)

One should be a Development instance.

Next you have your Test instance.

And finally, obviously, you will have a Production instance.

The Development Instance

As a ServiceNow Admin, I spend most of my time in this environment.

Don’t make the same mistake as many other companies.

ServiceNow was designed to make it super simple to build enhancements and promote them to other instances. Don’t have your end users or testers run any tests in development. While it’s possible, and your manager probably won’t even realize it’s happening, it’s just bad practice. Development is where you, the admin or developer, should be “building” out your enhancements and applications. And nothing else.

The development environment is obviously still a “junior test ground”, but for ServiceNow Admins only. Meaning, once you build out an enhancement, you’re obviously going to engage in some testing yourself to validate that it worked. But don’t get sloppy here, once you’ve confirmed that it works, it’s then time to push up to Test. Don’t invite your testers into Development.

The Test Instance

The test instance is all about your end users that are going to be testing your enhancements.

Once you’ve moved your update sets successfully to test, you can then direct your testers to login here and engage in rounds of testing. This is probably the least frequently used environment, but it’s a crucial step in the development lifecycle.

Your testers are going to expect that they’ll have the same exact experience in test as they will in production. This is your opportunity to give them that preview of what it will be like.

It’s important to document your testing. It’s easy to be nonchalant and sort of let this step go. Most people will just send a Slack message and say “Great work, move it up to production whenever.”

Which in theory sounds fine, but again, this is sloppy and bad practice. Documentation is an important supporting attribute to the testing process.

Proper documentation is really a CYA (Cover Your Ass) activity and will help to protect you in the future. If someone were to say, when or why did this happen, you can point them to the documentation and the sign off of the enhancement requesting team. You won’t get burnt this way.

Even if it’s just a simple Google Document where you briefly outline what’s been done, and your tester signs off on it.

Create A Change Request

This is another great way to provide documentation for work that you’re performing in the ServiceNow environment.

For all of your ServiceNow related enhancements, if you just create a quick Routine change, which doesn’t require CAB approval, you’re setting yourself up for success.

A Change Request or Documentation external to ServiceNow are both acceptable ways to track the work you’re pushing up to production.

The Production Instance

This is where all the magic happens.

Once an update set has been pushed to Test, the testers have confirmed that the new enhancement(s) are working as expected, you then finally push the update set to Production.

IT Change Windows

Some companies have these, and others don’t. It’s a window that’s defined by the Change Advisory Board (CAB), about when code can be pushed to production, and when it can’t.

Ideally, you’ll have an IT Change Window once a week, where you will push you code up to production. This way, you’re not expected to just push it randomly whenever something comes up.

A regular cadence will assist with your development and it will help to manage expectations on the side of the requesters.

Downclones and Software Upgrades

These two processes often work in tandem with one another.

Quarterly, or at least twice a year — you should be processing downclones of your ServiceNow data.

This means, taking production and cloning it over your sub production environments. This is a way to “true up” your data and keep everything in sync with one another.

Over time, small changes occur in production, and by down cloning, you ensure that you’re building in an environment that is similar to production.

Whenever you have an upgrade on the horizon, you should think about doing the following:

  • Downcloning Production over Sub Production instances
  • Upgrading Sub Production instances only (don’t do all at the same time)
  • Test the software upgrade in sub production, make sure ALL teams that use production are testing.
  • Only then, once approval and proper communications have gone out, do you schedule production to be upgraded.

Do you have any sensitive data in your ServiceNow environment? Maybe your company uses HR Case Management or Security Incident Management — just 2 examples of data that would be considered sensitive in nature. Most people on these teams don’t fully comprehend what the ServiceNow software development lifecycle looks like. They just see ServiceNow as a ticketing system, and even if you run a downclone, they still probably don’t realize that you’re taking all of their production data and moving it to an instance that’s not managed by them. Thus creating a security vulnerability.

Most teams focus on Production only, but security needs to be extended to sub-production instances as well. The best way to manage this is to control the data in these sub-production environments. Which means leaving out any sensitive data.

In this scenario, you will need to “Exclude Tables” in your next production down clone, on both the Target and Source instance for this to work properly.

You could always just write a background script to delete the data, post clone, but why not learn how to do it the right way?

By now, I hope to have convinced you to work in update sets and to never modify anything in production.

As you continue to grow from an Admin to a Developer in ServiceNow, you will become more comfortable with these concepts.

This article was created to help those that are starting out, if you’ve got several years of ServiceNow experience, I don’t think any of this will be new to you, but I also don’t think you would have finished the article either!

Be well and build great things!

ServiceNow is an ITSM Platform. We write about how to build applications and properly manage code on the ServiceNow Platform. We’ll recommend what to do, and what NOT to do. We aim at giving our end users the best user experience possible.

Recommended from Medium

Webify PDF Files in AEM using Adobe Cloud APIs

Scrum = communism (not)

Terraform Basic Pipeline

Two Truths and a Lie

Introducing the DADI testnet

Understanding Linux Systemctl

The Sorrow of Technical Debt

Effects of Docker Image Size on AutoScaling w.r.t Single and Multi-Node Kube Cluster

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Louis Waller

Louis Waller

A Silicon Valley based software engineer’s perspective on the world.

More from Medium

Outdated Vendor Software, or, When You Know It’s Time To Upgrade

Will Scrum be effective for Remote Software Development?

Living With Tinnitus For 7 Years — Tips To Manage It

Xmas knock-knock jokes