It’s the ServiceNow DevOps Pipeline, Dummy

Many ServiceNow customers think they have a “Code Quality” problem when they really have a “ServiceNow DevOps” problem. Here is why.

‍

When demand from the business grows and ServiceNow development starts to scale in the organization, the responsibility of the core platform teams to ensure a safe production release drives more stringent QA and release requirements for moving new code from development through testing instances. Finally, into production. These requirements typically include multiple code reviews, functional testing, integration testing, and an open slot on a scheduled production release. The long process slows everything down but is a necessary barrier against serious issues. When you add the isolated nature of ServiceNow development* the bottleneck of the release process keeps growing, causing backlog issues for the business and what looks like a “quality” problem for the platform owners., In fact, the process of getting changes to production fast enough is inefficient   and they are unable to synchronize changes between teams simultaneously, which would avoid many of the seeming “code” problems they currently face.

‍

The reason is that many issues like collisions, complex dependencies, and ordering problems simply occur, because code gets stuck in sub-prod instances for too long,  while disparate teams are unaware of the changes sitting in the pipeline as they continue to work on newer code on ServiceNow.

‍

Please understand me, though. Code quality and coding standards are essential in and of themselves. Still, without solving the pipeline problems first, high-quality code is exposed to time-related problems as dependencies cannot be solved early, stacking on more and more potential issues the longer it sits in the pipeline. The solution, of course, is to integrate code quality scans and checks into the delivery pipeline of your update sets and applications. Nevertheless, unless you’ve automated the pipeline you can’t get anywhere.

‍

ServiceNow is the most robust platform for creating business applications fast, but it is also very susceptible to these types of problems due to its fundamental, multi-instance architecture. ServiceNow makes it easy to build on any instance. It makes it easy to move changes from one instance to another using update sets and scoped applications, but as your footprint grows and more teams and more instances are put in place, the need for automation, real-time synchronization, and an integrated code quality and security process becomes a necessity  – In short what you need is smart ServiceNow DevOps However, building a smart ServiceNow Devops operation doesn’t mean you need to go the traditional DevOps way. Actually, in my opinion, this is exactly why you shouldn’t do. Since ServiceNow is a closed environment, it’s best to build native ServiceNow Devops capabilities, with the help of tools such as xtype, that helps you automate ServiceNow deployment and releases, a key pillar in your ServiceNow DevOps strategy.

‍

I can’t tell you how many times I’ve talked to customers who identified their problem as a quality problem when they had a DevOps problem. The good news is that this can be quickly fixed with the correct focus and action plan. Once you automate your process, increasing quality becomes much more pragmatic and data-driven than if you try to impose better coding standards on a broken and manual operation.

‍

*In ServiceNow, each instance is isolated from all other instances. There is no built-in synchronization between instances and no shared code-base. You develop in a walled garden that constantly moves away from the baseline, and all other instances as changes on it accumulate and end up having to clone down every couple of months.