Update Set Deployment - automating the preview and commit process

kevinanderson · ‎07-14-2016

So, I have been developing on ServiceNow for a little over a year now, and one of the biggest pain points for me has been the deployment of code. Update Sets are ugly in my opinion. As a web developer, I am used to pushing a bunch of files up to a server via a single sync from an ftp client, and then moving on. Deploying code via update sets in the ServiceNow UI is painful. Lots of clicks are required to get code migrated. It's slow. It's really awful.

In my current role, we often have large deployments. Sometimes there are hundreds of update sets. This means lots of clicks, often lots of errors and warnings, and long evenings during the day of go-live getting past all this.

I went to Knowledge16 and picked quite a few brains on how this could be improved. One good idea that was shown to me was the concept of overwriting update sets after they have been deployed. This is nice, as it helps keep our update set count down. Got and error moving an update set to QA? Go back to DEV, re-open the update set, capture the fix, go to QA, delete the received update set, and then pull the fixed update set back in and re-apply. Nice.

Ok, so now using this approach, we are in the tens of update sets instead of hundreds...still a LOT of clicking to get 20 or 30 update sets previewed and committed. I decided at the Knowledge16 hackathon to start working on a way to automate the deployment process.

My Approach would be:

1. pull in remote update sets via a script

2. auto preview the update sets

3. produce a preview report for ALL retrieved and previewed update sets

4. auto-commit all update sets with zero errors

Working with a few of my team mates, we hacked together a script include to achieve the above goals a few weeks after Knowledge16. I have since spent the last 2 months creating a UI page to interact with that script include to allow anyone to deploy update sets quickly. I would like to present the code here for you to take a look at. Please play with it, feedback is appreciated. This is version 1 of this code. It has not been battle tested yet, so use at your own risk. I DO NOT recommend this is used in production at this point.

A few of the features:

filter remote update sets to deploy by date created, release date, keyword matching
uses the native "remote instances" module in ServiceNow to fetch update sets from the remote system
filter the preview results by keyword, only clean update sets, only update sets with errors
print preview results
commit log displayed for all committed update sets

Update Set (attached)

auto-deploy_update_sets_v1.0_ka_sys_remote_update_set_.xml

u_client_templates (u_descriptionLIKEupdate set autodeployer).xml

Screen Shots:

iamabhishek · ‎05-05-2017

Okay no problem.Please do let me now if any hand required.

Thanks,

Abhishek

kevinanderson · ‎05-05-2017

Abhish,

Do you have a developer instance? I can post the latest update sets I have to the github repo, and we can co-ordinate from there.

What is the best way to contact you outside of SN Community?

iamabhishek · ‎05-05-2017

Kevin, i have my personal instance.

you can reach me through my phone number : 91-7387899960.

Or the best way we can talk?connect through skype : My skype id is abhishek.raj359

Thanks,

Abhishek

shashiranjan · ‎05-11-2017

Hi Kevin,

I am also interested work on.

Could you please provide me latest update set.

Thanks ,

Shashi

kevinanderson · ‎05-11-2017

After attending Knowledge 17 - it appears this idea is not worth pursuing any longer.

With the Jakarta release, SN is introducing the concept of parent- child relationships to update sets, that will allow us to bundle large number of update sets together under a single parent, and then use that to deploy to the target instance.

Its not a merge, the original update sets are preserved, but after the relationship is established, the bundled update sets can be previewed and committed all from the parent update set. It will enable very fast deployments, even when hundreds of update sets are involved, as they are all previewed and committed with 1 click from the parent.

shashiranjan · ‎05-11-2017

Wow! this is a nice concept.

Thanks Kevin for this good knowledge.

But as of now, I have to do auto deployment for helsinki.

Dont know how longer it'll take to upgrade in our instance.

This is my critical project for automation. Please help me out.

I have deployed you Update Set(V1) in my instance. But not able to set end point.

if you have created V2. Please let me know the link , from where i can get that update set.

And also guide me to set up endpoint if possible.

Thanks,

Shashi

kevinanderson · ‎05-15-2017

Here is what I have. See attached zip - v2.2. It has some issues:

1. remote sequence load point is really unnecessary. I think instead of loading update sets from remote, the form should provide a text field where you can paste the sequence, and then the application resolves the list provided with what can be found in the retrieved update sets

2. my data structure is not good. I used a separate client side collection for tracking all the different steps in loading the update sets (retrieved, previewed, committed, reports). Something is wrong, and the app is unable to properly load the update set state in the UI (incorrect load state, missing reports).

rezacol · ‎11-08-2017

Hi linkn@naitonwide.com

Could you please provide me the brief logic on how you were able to achieve the below scenario:

Retrieve completed update sets to the target instance — perhaps with a scheduled job. (We actually push the update set to the test instance when it is completed — we have a trick for doing that too).

Thanks

Reza

manjeet_kumar · ‎11-23-2017

Hi Reza,

our team has requirement to push completed update set to the test instance. you have written that you have trick to do that.

could you plz help me out.can u share any idea/code anything.it will be very helpful to me.

you can personally contact me on email: manjeet.kumar@infosys.com /8709358605

Thanks,

Manjeet Kumar

Foster Hardie · ‎06-14-2022

This is very interesting, even if 6-years-old. Was it ever completed?

I think a valid use case is in sub-prod test scenarios where the data needs to be as up-to-date as possible. I'm going to dig into this and see if it's still functional.