kevinanderson
Giga Guru

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:

Capture_updateset_autodeployer.JPG

Capture_updateset_autodeployer_print_preview.JPG

Capture_updateset_autodeployer_preview_filter.JPG

Capture_updateset_autodeployer_commit_log.JPG

35 Comments
kevinanderson
Giga Guru

I believe the technique was discussed in reference to a way to get to   cleaner update set for prod go live nights.   We were discussing ways to deal with large number of errors in update sets, and methods we could use between dev and qa environments to clean up issues in update sets before they go to production.



The overwrite technique would not be used in prod deployment, but could help us push back on a   developer in the lower environments to get them to clean up an update set of easily corrected errors, such as "found a record newer than the one in the update set".


marcelo_moreli
Mega Guru

Hi Kevin.



Great work! Do you have some other update on the last months you could share?


kevinanderson
Giga Guru

I just updated the files on the github repo with the last work I did in October.   Never got this working 100%.   I got close, but time has not allowed me to revisit this since that last update.



The update set has not been updated,   only the source files.   I lost my developer instance over the holidays and did not have a recent export of the update sets.


iamabhishek
Kilo Explorer

Hi Kevin ,



Great Work !!! I tried this one in my helsinki instance but could not able to automate the retrieve, preview and commit.


I am not getting any data on preview,retrieve and on commit panel.



Could you please help me with this ?



Regards,


abhi


kevinanderson
Giga Guru

@Abhishek Raj



did you setup the api endpoint on your lower system?



there are two version of the app in the github package.   which page where you using?   v2?


Abhishek Raj3
Tera Guru

Thanks Kevin ,


I have imported this update set (auto-deploy_update_sets_v1.0_ka_sys_remote_update_set_.xml) in my instance and i have a setup for   remote instance fo this process.


But couldn't figure it out where we have to setup API endpoint.


could you please guide me through the whole procedure.


kevinanderson
Giga Guru

v1.0 is tremendously buggy, and I do not remember if I ever got it fully working. look at the github repo link for the updated versions of the project.



The idea is as follows:



Remote fetch does not bring over completed on date or release field,   as I recall.   So the api endpoint is installed on what ever system you are pulling update sets up from into the environment the deployer is installed on, to allow you a way to query each update set for the correct sequence based on completed date (I hope that's right, It was last June I wrote 1.0).


kevinanderson
Giga Guru

I am looking to get this module rebuilt for service portal.   Anyone interested in working on this with me?   This project need strong   front-end Javascript developers and testers.


iamabhishek
Kilo Explorer

I am Interested to work.



Thanks,


Abhishek


kevinanderson
Giga Guru

I plan to pick this project up next week at knowledge 17 and work on it during the hackathon.