#New York Release, #Admin, #Cloning, #Delegated Development
Andrew Barnes
It is ServiceNow’s new release season! With the Orlando release in Early Access, we will show some platform features and enhancements that are a bit more admin focus.
Typically the developer blog focus on application development, but handling the instance and data also sometimes done by the developers.
Cloning
Configuring clones can take significant time, depending on how many instances and the complexity of the setup required. Clone profiles have been introduce in Orlando to help simplify and automate the process.
The profile allows you to set up different procedures for different instances/types of instances. Each profile has its settings for the general clone configurations. A new set of related lists allows for configuring Exclusions, Preservers, and Cleanup scripts.
The initial system_profile is not editable and is use to house the default exclusions, preservers, and cleanup scripts. You can adjust the related items to the system_profile to set up the components that are share between all clone profiles.
After creating new profiles and new related records like clean scripts, they can be added via the related list Edit button. An order field is now available on top of profiles for cleanup_scripts. The order field allows for correctly ordering cleanup scripts so that no out of order or dependencies are miss.
Clone Preserve Update Sets
You read that right. Preserve in progress update sets is now available. A new setting for clones is a checkbox that allows you to select to preserve any in-progress update sets from the last 90 days in the target instance.
You do need to be still concerned about completed update sets that have not made it up the pipeline to the clone source (typically production). The Orlando server update sets are import into the retrieve update set table and need to preview/commit to deploy.
Preserve Large Tables
It doesn’t always understand the implications of preserving large tables during a clone. ServiceNow would also like to understand the use cases around choosing to preserve those types of tables data.
To help with both of those points upon choosing to maintain large tables, a secondary prompt will appear. It will tell you which tables are large and ask for why you are wanting to copy so much data.
Scheduled Jobs TimeZones
Timezones can be scary. Don’t fear; this addition should be helpful. The sysauto and sys_trigger tables both contain two new fields.
*Timezone time_zone *Time entered_time
The two above fields will use together to allow for a user to enter in time, and time zone, and have that be when the scheduled job will run. The time field is using a new field type UTC, which will not adjust the entered time based on the user’s session as most time fields.
Cloning tips
ServiceNow and the Orlando community have put together tons of checklists and white papers on cloning. I want to call out a couple of things to help out that is not require. Before cloning and periodically, it is useful to Batch together older update sets.
Sort your local update set list with no parent and older than a month, create a new parent called ‘QX 202x batch’. Set all the update sets in your list to that parent.
The reduction in update sets that need to compare will reduce and will speed the retrieval of update sets post clone. Next, you can set all the update sets with no parent to ignore.
The ignore is done to prevent your instances from trying to retrieve these already retrieve update sets. The local update sets in production have unique sys_id’s and would otherwise be retrieve after cloning