Go to portal
Git blame is a known command for developers using Github. The command shows what revision and author last modified each line of a file. In ServiceNow there are also ways to see who did something and when. However when it comes to monitoring changes in the code per application or process, this can come a very tedious task. It is necessary to select each element individually, and then to check the versions for each of them one by one.
If you are using QC for ServiceNow, this becomes a trivial task. The code monitor dashboard provides you with full information about all the configuration added to an instance, broken down by application, in a single view.You can even display two scans at the same time, side by side, so that you can compare the configuration elements from one scan date to another and spot any differences with ease. This is especially useful when we want to compare what has been changed from one release to another or to spot differences between different ServiceNow instances (Dev-UAT for example)..
In the example below, the comparison of the configuration is within the same instance, but in different scan dates (7 July and 12 July).
We can easily identify that one new configuration element has been added between the two scan dates and 9 new lines of code customisations have been added to the instance. By examining the applications breakdown in the same dashboard, we can see that the new element is a Catalog Script.
Each element identified by QC for ServiceNow contains information such as the name of the element, the application it belongs to (whether its a modification to a ServiceNow plugin, a scoped application, or the global scope), who created the element and when, and a link to navigate directly to the definition of the element (by sysId). This is also useful when we want to monitor changes in particular applications. In some cases we may want to ensure that there are no changes in a particular table (e.g. no new dictionary entries have been added).
In the image below we can also see that the catalog script is calledVariableSetClientScriptQC.
This example is a deliberate simplification, but the code monitor dashboard becomes exponentially more useful when there are thousands of configuration elements and lines of code. As a QC for ServiceNow user, you can easily explore all the code in your instance, or filter by application if you want to focus your analysis on a specific area of functionality. Also, you can export the list of configuration elements to a CSV file so that you can perform any bespoke analysis using a spreadsheet.
Comparing different versions of our code in ServiceNow is now an easy task, even across different instances!
Which other uses would you give to this dashboard?
