It's undeniable to say that the ability to automatically search for best practice errors in an application does not help development and makes that product a more sustainable and safe product.
With CODA it's easy to achieve this feat in ServiceNow development, as you are constantly monitoring the quality of an instance. However, is there a way to further accelerate and anticipate this process?
CODA Agent
The answer is yes and it's already available for any user to enjoy. CODA Agent is a tool that allows the individual analysis of a record or even a specific update-set, and this directly from the instance. Install our update-set to enable targeted scans through an UI Action.
The installation of this update-set in your instance will enhance CODA capabilities and ease it's adoption into your daily development and administration routine.
What's included in the installation
The customer updates included in the CODA Agent update-set are:
- Dictionary Entry and Field label for update-set table;
- 5 System Properties;
- A page property with all CODA properties (including a CODA application and Property module);
- 3 UI Actions;
- 1 Script Include;
- 1 Form Layout;
The Script Include is where CODA stores all operating logic and external communication with the application, run() function, error validation, etc. The UI Actions are the SCAN buttons (present in the update-sets table and also in all unit records) and the “Last Scan” link available on the page of an update-set, after having analyzed it once (dictionary and field label are for this link). System Properties, in turn, serve to keep us in control and identify which instance CODA Agent is installed on. And the Form Layout, it's just to put the UI Actions on the forms.
How does CODA Agent work?
Record
The record analysis is the most basic of CODA since the necessary information is there in the record itself and the information to be analyzed is more punctual. The SCAN UI Action is a link between the application itself and the instance, it's through it that the communication between the two parties is set up.
When clicking on SCAN in a record, CODA captures the code and identification information of the record (such as table, name, last update) and then sends this data to CODA, where the analysis of this code and content is made.
With this data in hand, CODA's core builds a scan similar to the global one and then returns the results to the user, with a link (if there are issues) for him to be able to view them in CODA itself.
Update-set
For update-set analysis, the operation is a little different. Within an update-set, there are several records, each with its specific information, so it's necessary to analyze each one individually. However, doing this individual operation and in each record would be very costly and exhaustive, so the construction and capture of this data are done through the payload saved in each customer update of that update-set.
Within a payload of the customer update if a change within the US, there is all the information linked to that record. In this way, the job of searching for information about it becomes lighter and faster, since there is no real interaction with the record to be analyzed itself.
Upon completion of the update-set analysis, CODA returns the results to the user, just as it does with registration. However, when it comes to the update-set analysis, there is a crazy difference for the end-user. After running a scan, a related link appears in the form of this update-set, indicating which was the last scan run on it.
This facilitates control over that workflow and helps determine the next tasks and steps for development.
I've installed CODA Agent, what about now?
Each company has a specific workflow for your projects that mark the development, delivery, and maintenance processes. CODA Agent appears to become part of this process and a project manager is responsible for determining the best time for its use in some specific situation or project.
There is basically no rule for how it works. There are several possibilities, such as always analyzing at the end of a project, or during its development. Analyze every day, once a week.
The most important thing is to understand the advantages of having a tool like these in a developer's daily life. The power it brings to make a project healthier and with less maintenance and repair costs.
Organize recommendation
The goal of having a tool that analyzes code and configuration for bad development practices is to prevent these errors from growing and running out of control for maintenance in the future. With that in mind, we understand that an ideal time to make use of record analysis is during the development of those scripts, almost as a "real-time check".
In update-set, since they store an entire development work in a given interval, the analysis at the end of that period is perhaps the most recommended. Almost like a last stage of validation before this work is approved.