Update Set governance and naming convention

I’m kind of a process/quality geek. I like to keep many things consistent to make my life as a product owner and ServiceNow platform owner as easy as possible. At least when it comes to development governance and release planning. But I learned that having naming conventions and documentation on how to work with update sets might not be enough, especially when working with multiple vendors developing on the platform.

Therefore I wanted to find a system that makes my life and life of the developers easier. My idea was to leverage the Agile Development module, REST API, and Business rules. All of those in combination with Update Sets should fulfill my idea: Never have an update set without a reference to a user story!

The connection between naming convention and agile development

To bring this idea to life let me explain to my thoughts:

1. No update set deployment to QA without a story.
   I like to manage all work for the developers in user stories. This keeps it simple to connect the requirements with the developers and is a simple to use process in agile development. Unfortunately, if things have to go quick it gets dirty. Developers then ignore naming conventions and commit update sets without a reference to a story.
2. Follow the naming convention of “STRY…. – Story Short Description”
   For all developments, I prefer to name update sets starting with the story number. What is added afterward is less important, but the story is my reference.
3. Easy release preparation when the process is followed
   I prefer to create releases and assign all related user stories to the release. Shortly before the release, I want to create a batch update set containing all update sets of the stories belonging to that release. You can see at this point I need to have a consistent update set name to create a quality release in a short time period.

Check user stories in another instance before update set completion

If you use Agile Development in your production instance it will be simple to follow my idea. If you use other tools to track stories like Jira you have to adjust at least one piece of the solution which is the REST call to that system.

Before you can start here are some pre-requisites:

1. You have to have a user that can call a REST API in a production environment.
2. Create a Basic Auth credential record with that user.
3. Update the properties for the production instance and the product to which the stories are related.

To fulfill the three requirements above I created a business rule on the sys_update_set table. The business rule will:

1. Get the substring of the update set name containing the story number.
2. Create a GET REST call to the production environment.
3. Checks if the story number exists in the production environment.
4. Validates if the story is assigned to a sprint and not in DRAFT or CANCELED state.
5. Cancels action if there is no valid story.

The business rule runs after changing the state of the update set to COMPLETE. on insert or update.
There has been a fix to this script –> Go Here.

(function executeRule(current, previous /*null when async*/) {

	// Extract story number from the update set
	var number = current.getValue('name');
    number = number.substring(0, 11);
	
	// Set variables for the REST call
	var instance = gs.getProperty('tlgr.productionServiceNowEnvironment');
	var product = gs.getProperty('tlgr.productSysID');
	
	/* Get a result from the rm_story table in the production environment
	* Conditions:
	*      Product = ServiceNow (or whatever you mentioned as sysID in the property)
	*      Active = True
	*      State IS ONE OF Ready, Work In Progress, Ready for Testing, Testing
	*      Number starts with Number Substring
	* Return the number of the user story
	*/
    var endpoint = 'https://' + instance + '/api/now/table/rm_story?sysparm_query=sys_class_name%3Drm_story%5Eproduct%3D' + product + '%5Eactive%3Dtrue%5EstateIN1%2C2%2C-7%2C-8%5EsprintISNOTEMPTY%5EnumberSTARTSWITH' + number + '&sysparm_fields=number';
    
	
	// Create the REST call to production ServiceNow environment
	var request = new sn_ws.RESTMessageV2();
	request.setEndpoint(endpoint);
    request.setHttpMethod('GET');

	// Get the credentials from the credentials store
    var provider = new sn_cc.StandardCredentialsProvider();
    var credential = provider.getCredentialByID('c1b813702f630110f908f64ef699b6f3'); // Sys ID of your credentials

    var user = credential.getAttribute("user_name");
    var password = credential.getAttribute("password");
    request.setBasicAuth(user, password);
    request.setRequestHeader("Accept", "application/json");

    var response = request.execute();
	var responseBody = response.getBody();
	responseBody = JSON.parse(responseBody);

	// Check if the number of the update set has a valid story in production, if not abort the action and throw an error message.
    if (number != responseBody.result[0].number) {
        gs.addErrorMessage("Update Set can't be closed. Please check if naming convention is correct and user story is part of current sprint and in a state like Ready, WIP, Ready for Testing or Testing!");
        current.setAbortAction(true);
    }

})(current, previous);