How to stop a Hot Fix Update Set tripping up next Upgrade to a Scoped Application?

[David Hubbard]

We are trying to work out the "Hot Fix" process for our Scoped Application.

I am aware that, if changes are applied to application resources on a client instance then on next upgrade these items are likely to be "skipped". 

Obviously certain changes are expected on a client instance (e.g. a System Property value).  However applying the "Hot Fix Update Set" will likely change other resources (Script Includes, UI Pages etc) - which will need to be updated on next Upgrade.

If I apply an update in this situation I can see 

Skipping because of database override: update/sys_ui_page_840fd56a1b27551042b1c9d6624bcbc3.xml

I guess we could include some instructions in our upgrade installation note, but it feels cleaner if we can handle this in a consistent manner.

We will apply the code/config change back into our main code base, so it will be present in the next release/upgrade.

Is there a recommended way to handle this post Hot Fix (resetting a flag?) so that these "skip" actions don't happen on upgrade.

Thanks

David

[Philip Green]

You should be able to manage these skipped records the in the same way as you'd manage them for an upgrade.

Navigate to Upgrade Center > Upgrade History, change the 'History Type' filter from 'Upgrade' (e.g., to Plugin, Application, Update Set, etc.) and look for the entries you need showing 'Changes skipped'.  Then open the records and look at the related lists to revert skipped records to base system.

Here's an example screenshot showing a customised record (in this case a ServiceNow provided patch to a script include from the Service Builder plugin) about to be reverted to the base system.

[David Hubbard]

@Philip Green hi

Thanks for your response - I am aware how (as an admin of a specific system) I could manage this - however I was looking for a way to manage this from a application supplier perspective.   I am looking to avoid having to ask all clients sys admins to undertake those steps.

If I know that a hot fix update set will update (say) three resources when applied to each clients system - but can I also include a fix script in the update set that the client can also run to turn off this "marker" (that triggers the skip) on these resources after applying the update set?   

That should mean that when the next upgrade comes those items don't get skipped - the version deployed in the app release gets applied.

I guess I am asking two things:

1) Where is the "marker" (table/column) that gets set by applying the update set?  Such that a script could flip if back.

2) What is best practice here? - is it just accepted that Sys Admins will have to review the "Upgrade History" and we should just document that requirement?

Thanks

David 

[Philip Green]

Hi David,

The sys_update_xml table has the records of all changes applied to an instance I believe. Best practice I believe is for platform admins to review skipped records as they do with any upgrade so they can make a conscious decision whether to accept an update or stick with what they've got (they may have customised something for example and the rule is, once you customise something, you 'own' it).

[paki]

hi @David Hubbard 

this is something I actually need. What's your status now? There's also the selective commit when you connect a scope with a git repository but unfortunately we can't utilize this for other reasons. 

The solution proposal from @Philip Green  may be correct but is too error prone as a lot of developers need to follow a manual process.