ServiceNow platform engineering – Here’s why classic DevOps tools do not apply

Classic DevOps concepts and tools were built for file-based codebases and centered around a development stack that is fundamentally different from the packaged platform architecture of ServiceNow (as well as many other platforms like Salesforce, for example). To understand this deeply, here is a detailed historical and technical overview of DevOps, its core concepts and components, and how things are different in ServiceNow DevOps. The good news is that there is a native way of achieving the same great benefits in ServiceNow, only in a slightly different way. Anyway, let’s dive in.

History of DevOps

The word DevOps was coined by Patrick Debois in 2009 when he created the first DevOpsDays in Ghent, Belgium (where he lived). Patrick was inspired earlier by the “10 Deploys per Day: Dev and Ops Cooperation at Flikr” presentation by John Allspaw and Paul Hammond at the 2009 Velocity conference. Ironically, Patrick was not at that conference but was inspired by their presentation, organized the first DevOps conference, and thus coined the word.

The backstory to 2009 is that in 2008 Patrick and Andrew Schafer were the only attendees to a “birds of a feather” session focused on applying Agile principles to infrastructure. Though they were the only two who showed interest at that moment, Patrick and Andrew put together their thoughts and quickly gathered a following, including John Willis. The collaborative effort between these like-minded individuals prepared Patrick to take (what must have seemed intuitive) the next evolutionary step in coining DevOps.

What Exactly Is DevOps?

Hopefully, the short history outlined above demonstrates that DevOps is a philosophy that has evolved from decades of experience and learning writing, deploying, and supporting code. DevOps embraces Agile, Continuous Integration, and Continuous Delivery practices and prescriptions. Adopting DevOps often requires a culture shift at organizations more than it requires the purchasing of specific tooling. That said, a large ecosystem of tools, ISVs, and consultants has emerged to support DevOps adoption and transformation.

If you ask ten people to define DevOps, you will probably get ten different answers though their answers will share common elements and themes. For purposes of this article, I will define DevOps like this: DevOps allows small teams to independently develop, test, and deploy code quickly, securely, and reliably to customers, while simultaneously allowing these teams to fail fast safely. Most in the DevOps community talk about failing fast, but in my experience, failing safely is more important than failing fast alone. Production failure in the financial services or healthcare industries can have heavy consequences.

DevOps Tools

As I mentioned above, there is an ecosystem of tools, vendors, and consultants in the DevOps market space. DevOps tools have evolved based on decades of experience to address the challenges and collaboration needs of multiple developers and teams writing and saving code in multiple files. Managing the myriad changes across countless files and lines within these files had been a real challenge.

DevOps tools that provide planning and track user stories are valuable for applying DevOps to ServiceNow development. But, CI/CD tools are unsuitable because they were designed to solve the challenges of file-based applications. However, for a platform-based application, you don’t own the overwhelming majority of the code, and your code isn’t managed in files natively.

CI/CD For ServiceNow?

Version Control
Version Control Systems (VCS) such as git are great tools for managing changes made in multiple files by multiple people. But VCSs are not great for managing ServiceNow XML dumps because the exported XML files are serialized system dumps that contain platform-specific data elements. ServiceNow XML files may contain some human-written code, but often the code you write isn’t actually exported. Instead, only the record locators that point to your code are exported. When you import an update set, ServiceNow will retrieve the code from the remote instance. At the end of the day, ServiceNow XML files are built by the platform, for the platform.

The benefits of merging branches that contain XML dumps are negated because the GUIDs, SYS IDS, Hash IDs, and hundreds of other system-dependent declarations will always differ between ServiceNow instances. Additionally, VCSs assume there is a master branch – the final version of the truth that all branches must ultimately be reconciled (merged) to.

This concept doesn’t precisely exist in ServiceNow. The closest thing to a master branch in ServiceNow is your PROD instance. It makes no sense to export your entire PROD instance into a VCS and then create branches from this because the inevitable conflict resolution that must occur will occur later in your PROD instance, NOT in a VCS. And how would you reconcile the conflicts between all the system-generated data anyway?

Demanding that any of your ServiceNow specialists learn yet another tool, such as git or any other VCS, and then context switch between the two tools will cause productivity losses. Research shows that, on average, those who context switch experience a 40% decrease in productivity compared to those who don’t. ServiceNow professionals already face a growing backlog from increased demand. Why exacerbate the lead time to delivery by demanding ServiceNow specialists learn a new tool that isn’t a design fit for their work?

CI & CI Tools
Continuous Integration (CI) is the practice of continually integrating or merging the code changes made by individual software developers. CI is a well-established practice in modern, high-performing software engineering organizations. There are many CI tools, such as Jenkins, GitLab, and Travis CI, to name just a few. CI enables you to scale up both the headcount and delivery output of engineering teams. CI allows multiple developers to work independently on features in parallel. When they are ready to merge their features into the main branch (end product), they can do so independently and receive rapid feedback on the success or failure of the code changes they made.

There is a difference between CI the practice and CI the tool(s). For file-based applications, CI is critical for merging multiple developers’ changes into an interoperable whole. The end for file-based applications is the master branch. For ServiceNow, the master branch is your PROD instance, and you typically clone it to provide developers with a development environment. Since CI tools are external to ServiceNow, what is there to merge? You can export some update sets, data, apps, and other ServiceNow items, but not all ServiceNow items can be exported. As already mentioned, most of the code in the exported XML files is system generated.

ServiceNow has built-in mechanisms for promoting or migrating changes from one instance into another instance. ServiceNow also alerts you to conflicts between two or more deployments. VCSs are incapable of providing a comparable experience for ServiceNow because, being non-native to ServiceNow, an unnecessary bi-directional conversion is required. This conversion adds extra work without clear benefit or improvement to productivity throughput.

Code Reviews
The concept of code reviews has been around long before DevOps and CI/CD. Code reviews are a manual gate-check for code changes before merging them to the trunk branch. The purpose of code reviews was to ensure quality and security by preventing developers from making the mistakes or errors associated with working in silos. It can also help ensure that coding standards and best practices are followed for any project. Some tools can automatically scan code to ensure conformance to syntax best practices and highlight potential risks.

However, just as before, what exactly are you reviewing when it comes to ServiceNow? The platform represents or generates 99% of the code base for an application or update set. You don’t own that code, nor are you responsible for maintaining it. Additionally, the XML files you would presumably review are a dizzying collection of TL;DR serialized tokens, tags, and IDs. The ServiceNow XML dumps were designed for the platform to ingest – humans were not the designed consumer. There is little to be gained by performing code reviews for ServiceNow code.

Conclusion

The guiding principle in attempting to “DevOps” ServiceNow development and migration should not simply be to apply DevOps tools. Taking this approach is like the classic idiom of trying to force a square peg in a round hole. Forcing file-based tooling on platform-built functionality will exacerbate and magnify the problems you are actually trying to solve.

Imagine applying tools and techniques meant for combustion engines to an electric vehicle. Certain concepts and principles for servicing vehicles will translate to servicing electric cars, but the specific tools and prescriptions will not. The challenge before us as DevOp practitioners and ServiceNow professionals is not to confuse the DevOps philosophy with DevOps tools. ServiceNow DevOps needs to embrace, utilize and take advantage of native ServiceNow functionality and capability along with DevOps principles to achieve DevOps and CI/CD outcomes.