The DevOps Mindset for ServiceNow Instances – Part 1

It’s been close to 15 years since the term DevOps was coined, became a movement, and then became a philosophical practice that improved upon the drawback of Agile. The benefits of DevOps do not need to be stated, but I wonder if it is time for another improvement. IDC projects that 750 new applications will be built over the next three years. Given the plethora of options to code these apps, it is likely that a significant percentage of these apps will be developed on low-code, no-code, or platforms such as ServiceNow and Salesforce. To categorically assume that traditional DevOps tools will meet the needs for platforms such as ServiceNow and Salesforce to achieve DevOps nirvana is naive and parochial. In these two blogs, I want to highlight some of DevOps tools’ shortcomings in supporting ServiceNow application development and provide some thoughts and principles for a way forward.

‍

ServiceNow Instances – I Don’t Git It

Git is an open-source version control system created in 2005 by Linus Torvalds to help develop the Linux kernel. It does a great job tracking code changes and enabling non-linear software development between many developers. Code changes can be managed, tracked, and merged into a master branch that can then be released. Git works great for file-based software development. The “deployable” application is a collection of files that overwrite existing files on the target server or container. What about platform-based applications that have more in common with RDBMS systems than with file systems?

Source: Perveez, S. H. (2022, July 12). What is git: Features, command and workflow in git. Simplilearn.com.

In a typical, oversimplified git workflow, a developer will work on a separate copy or clone of a master, make their changes, and commit them back to the master, where the changes from multiple developers are merged. The challenge with ServiceNow is that the commit and merge happen outside of ServiceNow, and developers are coding their changes in separate instances. A ServiceNow instance represents an ecosystem, not a filesystem. Code merges on git don’t represent an equivalent merge across the individual ServiceNow instances developers work in. In other words, developers in one instance have no idea how the platform has been adapted or updated by developers in other instances.

‍

ServiceNow Instances – Ecosystems vs Filesystems

Decades of experience have led to modern applications being architected and designed into smaller and smaller components allowing changes to be smaller too. Tiny changes reduce the likelihood of outages, require smaller change windows (if at all), and enable more frequent updates. The ServiceNow platform allows for micro changes that can be frequently released too. However, there is a difference between a platform-based app architecture and a file-based one. Because ServiceNow provides so many services and infrastructural operations, app development is rapid. However, this also means there is more connective tissue between a code change in a platform-built app than in a file-based one.

Changes in one ServiceNow instance need to be rapidly deployed or synchronized to other sub-prod instances because the changes from one developer can significantly impact the coding efforts of a developer in another instance – perhaps even negating, undoing, or duplicating their coding efforts. Externalizing these changes and merging them in a system like git doesn’t correct this problem. It exacerbates the situation and will force developers or release managers to sort through a git report and match that against what exists on the target instance. This effort is highly laborious and error-prone. Inserting more manual and error-prone work is the antithesis of what ServiceNow DevOps is trying to accomplish. At its heart, the DevOps philosophy is about frequency, velocity, and efficiency.

‍

I also invite you to read part 2 of this series, where I discuss what capabilities ServiceNow DevOps teams need to maximize their coding output.