Tips for Optimizing your ServiceNow Instance Management
Having been in the ServiceNow business for over 12 years, you begin to take certain things for granted. At least until you see someone doing something that you don’t expect and it makes you say, “hmm, maybe this isn’t common knowledge”. One such area where I’ve noticed this in recent years is the management of an overall ServiceNow environment – that which encompasses all your ServiceNow instances, and the processes and techniques by which configuration, code and data is built, moved and shared between them. In my experience, if done properly, this should be a minor undertaking from a time and manpower perspective. However, I’ve witnessed customers having teams of people and days of effort to manage this. To this end, I’ll share my experiences in how I was able to make this exercise a minimal part of your ServiceNow time within the SDLC.
Ways to maximize your environment management efficiency:
- Time-box your update sets. This means using one update set per application scope per development period. Why? When developers are working in the same application space, and sometimes even when they are not, they may work on the same element within the development timeframe. If they are working in their own update sets, if they are moved out of order, you will have to resolve conflicts on the destination instance(s). Here’s an example (we’ll use an Agile environment):
- Developer Bob has a Story to add a field to the Incident form in the main section (0) and creates a Story-based update set to capture his work.
- Developer Jenny has a Story to remove a field from the Incident form in section 2 and creates a Story-based update set to capture her work.
- Jenny finishes her work first and demos the change to the business owners. She received feedback that they actually want the field in section 3 now.
- In the meantime, Bob finishes his work, demos it, and receives sign-off.
- Jenny makes the updates asked for, demos it, and receives sign-off.
- Jenny moves her update set to TEST and commits it.
- The next day, Bob moves his update set to TEST and receives a warning that a newer update exists for the Incident form. He now has to resolve the conflict and hopefully not overwrite the latest version of the form.
This is obviously a very basic example, but gives you the idea. This could apply to almost any element in the system – Form and List views, Business Rules, Script Includes, Flows and Workflows, etc. In case you’re wondering – and I want to be very clear on this – Application Scoping does not help with this. In this example, both would be working in the same scope, and there are exactly zero reasons why you should ever do scopes by story or developer.
The last thing I’ll say on this point is that the concept applies whether you are doing project-based work – e.g. deploying a new application or releasing a large set of functional changes – or managing ongoing maintenance and enhancements. Either situation should include time-boxed development cycles if the development organization entity is being run properly.
- Make your production instance the source of truth for core data. Core data includes Locations, Departments, Vendors, etc; but it also includes Users and Groups. If you make production your source of truth* (* – at least within your ServiceNow environment – I’m not suggesting ServiceNow should be a source of truth for any of this data), you can create and update these records in production and XML export them back to your sub-production environments. In this way, they will always have the same sys_ids and configuration using them will not fail.There may be scenarios where you absolutely cannot have this data in production prior to “going live” with what you are developing. (I’m thinking of a new Assignment Group that cannot show in the pick list until the new development is live.) In this situation, create in your development environment, and document its move to test and production as part of your go-live planning.
- Make cloning a standard process occurrence. This applies to ongoing environment management rather than a new customer going live on ServiceNow for the first time. As an organization, make it a standard to clone your sub-production environments from production on a regular, scheduled basis. And then actually do it. Here are the benefits:
- It keeps the environments in sync – what’s been released in production is reflected in sub-production. This makes regression testing easier. It also makes upgrade testing easier – if your upgrade works in sub-production you can have confidence it will work in production.
- It settles your development lifecycle into a cadence. If your developers get used to wrapping up their work within certain timeframes, and having code freezes in certain timeframes, it will make your processes better align with SLDC standards, and make for a less chaotic development environment overall.
This is not without challenges. For instance, the clone schedule may coincide with urgent incident resolution or longer-term project-style implementations. We’ll talk about managing and mitigating these a little later.
- Use the Update source – Remote Instance records to move update sets. ServiceNow has the setup to allow you to connect to other instances and pull all completed Update Sets from that instance that don’t already exist in the destination instance. Contrast this with using the XML Export and Import functionality to do it manually. (I assumed this was common knowledge but I see a lot of developers and admins doing it the “XML” way.)
Here’s a diagram of the process I used at Workday (as a customer). This is a 4-week view, and is one full cycle of two (2) Sprints and a clone back at the end of the 4-week period. To the earlier points, the update sets were limited to one per Sprint per Application Scope.
At the end of each Sprint, we used the last 2 days to move code to TEST, do our regression testing, and move to PROD. After the second Sprint and the finalization of code moves, we would use the weekend to clone back to TEST and DEV (one per day). We would also use the code freeze days to complete our documentation and do other system maintenance activities.
A few other notes about moving code and configuration in 2 week Sprint cycles:
- Urgent fixes (Incidents) should be managed separately in their own update sets and moved “out of band” – outside of the normal Sprint cycle – in order to maintain a stable environment. (And of course as part of a Change Management process.)
- For longer term development projects where the work cannot be completed in 2 weeks, whenever possible incorporate the idea of a modified “walking skeleton” in order to close and move update sets in the normal time frames. This involves moving the code and configuration to production but hiding it until ready for go-live – inactivating the visible components, or making visible to admins only, so end users don’t see it.
- For exceptions that cannot be dealt with in any of the previous ways, use the XML export of the update set to back up unfinished work before the clone, then re-import and set back to In progress. Or, move the update set to production and leave in a loaded or previewed state. I haven’t found one to be better than the other, pick one and make it the standard.
I’m just beginning to scratch the surface on some of this, but I hope this gives you a general sense of how you can minimize your environment management efforts. As I say, in my experience, most of the activities using these techniques became rote and took little time in the overall SDLC. If you’re spending more than an hour or two a week, and it takes more than one person, consider some changes.
“Efficiency is doing better what is already being done.”
