The DevOps Mindset for ServiceNow Instances – Part 2

In my previous blog post, it may have seemed like I really picked on git. The reality couldn’t be further from the truth. Git is a valuable library for storing certain ServiceNow artifacts, but I am pointing out the limitations git has in addressing the fundamental realities of ServiceNow SDLCs in combination with platform-built app architectures. In this blog, I will elaborate on what capabilities DevOps teams need to maximize their coding output.

‍

ServiceNow Changes the Packaging Mashup

ServiceNow apps, scripts, and XML are not the only assets involved in a production deployment, nor are they the only things to be tracked in a CI/CD pipeline.  ServiceNow production pushes will frequently include plugins, plugin activation, data loading, script execution, and update sets.  An appropriate DevOps solution for ServiceNow needs to have all of these things and organize them into a “deployable” package that represents the production “payload.”

Taking advantage of native ServiceNow capabilities in any continuous delivery automation mechanics provides the best support for activating plugins, loading data, executing scripts, and deploying apps, scripts, and XML files.  Implementing automation mechanics external to ServiceNow may reduce visibility and increase manual work requirements since the platform is the only version of the truth that matters.

‍

ServiceNow Releases – Syncing vs. Merging

Merging changes from multiple branches works quite well for file-based applications. It works reasonably well for ServiceNow app development though it requires you to handle the merging and conflict resolution outside of ServiceNow. This manual work in a tool external to ServiceNow is not laborious by any stretch, but couldn’t there be a better way that takes into account the architectural nature of ServiceNow?  

In the DevOps philosophy, quick, accurate, and continuous feedback is one of the most effective ways to increase the safety of product releases, improve code quality and enable high-velocity and frequent releases. What if this feedback could be automated across all sub-prod instances? Imagine a developer making a change in their Dev instance, pushing it to a QA instance, and having those changes back-synced automatically to all other developer instances? This back-sync will immediately communicate the changes to other developers, reduce coding collisions and increase code quality as every developer will continuously work from a standard “image.”

‍

ServiceNow Releases – Knowing Is Half The Battle

One of the biggest challenges with ServiceNow releases is getting your arms around what is going to be included in this release. Considerable amounts of time and effort and made reviewing spreadsheets, conferring with multiple developers, and ensuring the quality and relevance of the data in the spreadsheets upon which you are basing your off-hours work. It seems unthinkable, if not a DevOps anti-pattern that all the CI/CD automation will culminate in manually intensive and error-prone work.

Many organizations just give up and regularly clone production, often incurring additional ServiceNow licensing costs. But if we can automatically back-sync sub-prod instances, then we are also in a position to have a concise and continually updated view of what changes exist in which ServiceNow instance and what package of changes are ready for production deployment.

No matter what DevOps tools you use, they have their place and appropriate use. What I am advocating is a thorough reflection on the context and realities of platform-based ecosystems and using the right tool for the right job rather than blindly applying ALL file-based app-dev tools to platform-based ecosystems such as ServiceNow. It seems to me that a combination of traditional DevOps tools along with apps native to ServiceNow that address the challenges I have written about is the best way forward.