Improving ServiceNow DevOps Flow Metrics: Mean Time to Detect

Reducing MTTD with xtype

In traditional software development, MTTD refers to the time it takes from when faulty code is committed to when the resulting bug is detected. However, ServiceNow development differs since update sets and apps are not typically committed to a Version Control System (VCS). Instead, developers mark their update sets as "complete" or an app ready for migration to your QA/Test instance. Most enterprises have mature processes that kick in to ensure safety and compliance as changes are propagated downstream to production. How can the DevOps Flow Metric of MTTD be applied to the Now platform and be improved? 

A Typical MTTD Flow

1. One or more developers make changes in the Dev instance
2. The changes are captured in one or more update sets or an app
3. The update sets, update set batch(es), or apps are then scheduled to be migrated to a Test instance
4. Testing happens (manual and automated) in Test, where bugs are detected and sent to developers to fix

Strategies For Reducing MTTD

Shifting Error Awareness Left

One of the challenges with developing on the Now platform is that sub-prod instances look different from production and different from each other. This difference means preview problems and errors are potentially baked into every update set or app developed. The problem is that developers will not learn of these problems until days or weeks have passed when their work is migrated to the next instance.

xtype solves environment inconsistency by synchronizing downstream changes upstream. This synching means all sub-prod instances are as production-like as possible and look alike. Developing in replicant instances reduces the likelihood of preview errors or dependency problems from happening in the first place. Errors that do occur at the time a developer is working in their environment and not days or weeks later in another environment.

Discovering preview errors or dependency issues at development time improves the quality of code produced while reducing the time spent troubleshooting these issues downstream. In this case, MTTD is virtually instantaneous, which catches a developer at their peak efficiency to remediate errors because they occur in the context of the work they are currently performing.

Migrate One Update Set at a Time

Unless there are dependencies, do not wait to batch update sets or migrate a collection of changes listed on a spreadsheet. Prolonging deployment of change elongates the troubleshooting process because developers will troubleshoot issues out of the context of their current development efforts. Remember, developers don't sit and wait after an update set is marked as "complete." They continue to the next user story.

This delay means they must remember what they were doing days or weeks ago to contextualize their efforts. Also, without synchronization, developers have to figure out the difference between the instance they are troubleshooting and the instance they developed on. Environment homogeneity can not be assumed, so differences must be investigated and ruled out as culprits.

It is easier to troubleshoot a single update set or app than it is a whole list of changes. When you bulk release by spreadsheet, there are dozens of changes that have to be sorted through. When you release a single update set at a time, only one change has to be investigated (plus environment inconsistencies). Reducing the amount of change released at a time shortens the MTTD and the MTTR (mean time to resolution).

xtype Controlled Synchronization Reduces MTTD

xtype's controlled synchronization allows developers to proactively detect issues while writing code rather than days or weeks later. It also ensures all sub-prod instances are as production-like as possible, reducing the likelihood of errors occurring during deployments. Put another way, if an error occurs in a sub-prod instance, you have a high probability that it will happen in production, allowing you to be proactive with your deployments.

The most impressive feature of xtype's controlled synchronization is that it remembers your remediation steps and will perform them as it synchronizes your update sets, apps, and batches. Teams that leverage xtype will benefit from higher quality code, faster release velocity, and reduced risk of delays.

In summary, xtype enables proactive bug detection by giving developers instant access to changes made throughout your ServiceNow landscape. Instead of waiting days or weeks to find bugs, issues can be spotted within seconds or minutes of a change being made downstream. xtype controlled synchronization ensures instance homogeneity, which shifts errors left to development, minimizes MTTD and prevents downstream delays in ServiceNow releases.

‍