Monthly hotfix/security patch testing best practice

[Eric Gilmore]

I haven't stumbled across this yet. But has anyone done a write up on the best practice when testing the monthly hotfixes/patches applied to the instances?

Personally I've never run into a situation where these affected any instance I've maintained negatively. But I've also never seen any documentation about what is recommended testing practice after a patch has been applied.

Any input would be appreciated. 

[bammar · Accepted solution]

Hello,

3 days no answer so ill throw my hat in the ring. By no means is my advice end all be all but ill tell you what you can do - you can pick any and all from the suggestions but if i was in control id be practical and not impose things on myself that are unecessary and have no utility. 

You could conduct a risk assessment for each every month. That would entail.

1. Pouring over the Release notes for the upcoming Patch - if you see anything new or a fix to an issue your having that would benefit your org - keep it in mind for something you may take advantage of or communicate about

2. In Sub prod which gets updated first - after the update go to that instance and check the SKIPPED changes - see if an update was skipped due to customizations- use a best effort to comprehend them and in a rare case if you want the update you can apply it- remember that and do that later after update in prod- most cases your customization was for a reason - you may see many updates skipped like for form customizations etc nothing to worry about but keeping the updates in mind is good especially if new fields were added- this is where release notes help. 

Considerations-

• Most of the time things that are patched are not detectable or noticieble- a problem you never even realized existed in an obscure area of SNOW may be fixed and thats great, i dont know half the things my phone gets installed when i have a forced update
• These are mandatory - we have no recourse or ability to stop these- so even if we find something we dont like or something malfunctions after the update in subprod- we can only report to servicenow and hope its fixed soon. 
• You can delay them only to the end of the month of the patch, sometimes if you have a Version upgrade to be done in the early part of the mth- you can game the system by delaying ALL to end of month and by virtue of a Version upgrade ala Orlando to Paris, you become compliant 

[Eric Gilmore]

@bammar Thank you for the info about skipped changes. I didn't consider that, but will from now on.

What I've also decided to do is create a suite of standard patching tests that checks the spaces where we've deviated (customizations) from the OOTB processes. In addition I'll now check skipped changes as well.

[bammar]

As the months fly by you may find it tedious, i would say regression testing is a little much as sometimes there are changes that dont relate to anything you use... I have never ever seen a monthly patch that made service now go haywire, if it wasnt for my companies compliance and SOP's i would just let the updates go with no time commited to them aside from reading release notes. After all we have no choice we must install these patches.... however knowledge is power- you may see something once in a blue moon that enhances something you use OR fixes a defect you were wating to be fixed- You are allowed to delay the patches toward the end of the moth too- so theoretically you can delay the sub prod to say the 20th and prod to the 30th this way if a company installed the patch on the 5th - they may report issues to ServiceNow ahead of when youll see them in prod etc. Also thank you for appreciating my comments- as long as you work with your concern being the smooth performance of your instance and continuous availability youll be fine.