3 Reasons CI/CD Integrations Fail to Address Your ServiceNow Backlog

We’re all familiar with Continuous Integration (CI) – the practice of merging (or integrating) your source code changes, several times a day, made by developers into a deliverable project. ‘Integration’ is the watchword here – and it helps explain why applying CI tools to ServiceNow is so tricky. To understand why, let’s go back to basics, beginning with the version control system (VCS). Tools like Git help you manage your source code files, merge changes from developers, and deal with conflicts. When you commit multiple VCS changes per day as part of the CI process, it kicks off a prescribed workflow (see Figure 1). The automated workflow picks up conflicts, builds binaries, performs post-build testing, and deploys the application to a CI environment. After that, the CD pipeline kicks in and includes a series of test automation tasks.

At every step, there are checks. If a problem occurs, the CI build fails and switches back to the developers for failure remediation. So why does this CI process fail to address the ServiceNow backlog? Let’s examine three mistakes people make applying CI/CD in their ServiceNow environment.

Mistake #1: You are assuming a CI tool will expedite the delivery of your ServiceNow backlog.

What’s wrong with this assumption? After all, the tools described above are designed to automate your CI workflow.

Here’s the problem. In ServiceNow, many of these CI automation processes are superfluous in the ServiceNow context. For example, when Git or another VCS tool identifies conflicts, what conflicts is it identifying? Classically, VCS tools identify conflicts in source code (text) files. Source code is the underlying building block for file-based apps, so identifying the conflicts before the code is transformed into binaries is essential. For platforms like ServiceNow, the platform itself is the building block for your coded features, customizations, configurations, or apps. Identifying a conflict in a ServiceNow export (XML file) is not equivalent to identifying a conflict between update sets in two instances.

Automated binary testing? For ServiceNow, no binaries are being built, so this classic CI automation step is unnecessary. Application-level testing does apply to your ServiceNow customizations, features, and changes, but why relegate this function to a CI tool when ServiceNow already provides a native Automated Test Framework for this purpose? Make no mistake, ServiceNow incorporates so many native automation and test capabilities that adding a CI tool adds delay, overhead, and expertise.

Mistake #2: You think ServiceNow exports are source code.

What’s wrong with this assumption? After all, the tools described above are designed to automate your CI workflow.We have news for you: Those ServiceNow exports are not source code. Your export files (XML) contain an array of machine-specific criteria, from GUIDs to record locators and various system IDs and tags. These IDs are unique for each instance, which means a VCS tool will incorrectly recognize differences between export files as either new “code” or changed “code,” neither of which is correct. The XML files can be so big and contain so many unique identifiers that a VCS will likely flag thousands of conflicts that don’t need to be resolved. The XML exports are intended not for humans to read and understand but for a ServiceNow instance to interpret. The design use case for CI tools does not match the ServiceNow reality.

Yes, ServiceNow exports do contain your coded features, customization, and configurations. However, it only includes some of them. The XML files contain record locators that point to your “code” on remote instances. Without access to these remote instances importing the XML files will fail. Additionally, ServiceNow exports do not include everything you want to migrate across instances, such as data, plugins, plugin activations, update sets, other XML files, and more. So if XML exports only include a portion of what you need to migrate across instances, what benefit are CI tools providing?

Mistake #3: You assume a VCS will work for ServiceNow the same way it works for file-based development.

To explain this, let’s start by looking at what you are putting into a VCS. For ServiceNow, you are adding XML exports – but as we’ve seen, these don’t cover everything you need, and the exports are not to be confused with source code. This difference brings us to the enormous difference between classic software engineering and platform engineering – and it’s a design bias baked into every CI tool. In traditional software engineering, you have your source code files (text files) that developers author and modify. CI tools assume that what you are moving and automating is a collection of text files that will be compiled into binaries or shippable packages.

Platform engineering is different. With ServiceNow, up to 98% of the functionality that your features, customizations, configurations, and changes depend on is already provided by ServiceNow from within the platform. Put another way, software is made up of two kinds of high-level code – application logic and business logic. For traditional file-based software, developers must write both the application and business logic. Application logic is code that allows the software to interoperate with its host ecosystem (OS, infrastructure, filesystem, database, etc.). For ServiceNow, the application logic is provided out of the box as part of the platform allowing developers to focus on building business logic and rules.

Since you don’t own nor have access to up to 98% of the “code” for your business solutions, using a CI tool is redundant. The features, customizations, configurations, and apps you develop in ServiceNow assume the platform will provide a robust set of functionality, services, and capabilities.

xtype dramatically reduces your backlog

xtype applies CI as a set of principles adapted to native ServiceNow assets and out-of-the-box functionality. xtype automatically tracks all update sets across your ServiceNow instances and allows you to group, name, and version them into a release. These releases are then automated forward to your production instance(s) using native ServiceNow automation mechanics.

xtype also synchronizes backward all the update sets migrated forward so that all sub-prod instances have the latest version of any change or hot-fix. This synchronization loop ensures developers are constantly working against the latest updates, which reduces conflicts and troubleshooting. Instance synchronization also reduces the need to clone and shortens the lead time to usability after you have performed a clone.

To discover how xtype can help your organization increase ServiceNow ROI, reduce your undeployed backlog, and increase productivity, visit ServiceNow ROI & Value Calculator.