Best Practice For Cloning During Long-Term Projects

[cmsrenaski]

I tend to put all of my questions in the Developer Community - please let me know if this belongs somewhere else. We currently clone quarterly. Once per quarter we are either upgrading or applying quarterly patches and we always clone from PROD to DEV and TEST before doing so. This works for most but we do have a couple of project managers that struggle with this concept as they have long-running proof-of-concept projects where we have vendors developing to prove a concept and our clones disrupt that process. When we went to K18 we heard that best practice is to clone more often, perhaps monthly, which causes our PMs a lot of consternation.

In general, I know that everything can be exported via update sets and data can be exported, however, there seem to be some applications where that is difficult. You're building things that cannot be easily exported. PA Dashboards are one example. Our PM also mentions Service Mapping (Service Watch) and Event Management. Per our PM, "We also have issues with other areas like Service Portfolio and PPS where the update set does not include all of the ‘Release’ steps. We still need to manually run steps like data loads, running scripts to repopulate historical field updates, etc.…"

Does anyone have any advice on how to accommodate long-running POCs (or just development efforts that can't be easily transferred between instances) while maintaining a prudent cloning schedule?

Thanks in advance for the help!

[mishu1]

Hi,

The clone frequency is also tied to the release cycle frequency/deployment frequency which is followed for a particular account/project. 

For example- let's say you have a major release comprising of deployments for a new application/existing application once in a month and then you have bi-weekly maintenance or minor releases comprising of bugs, minor enhancements, product fixes, known errors etc., in this case its best to clone your sub-prod Instances from the Prod Instance post the completion of each major Release in a month. This will make sure that even your maintenance/minor release work gets cloned over to your sub-prod Instance as the major Release is usually done during the last week of a month, where as minor Release will take place during the 2nd week or so. 

In addition to this, its always advisable to have your Dev. work being carried out in the Dev/Sandbox Instances in update sets containers and then once the cloning gets completed, those update sets can be imported back on the sub-prod Instances. Or, the concept of having different environments for Dev. work can also work, if in case your account has the flexibility to procure more Dev./Sandbox Instances from your ServiceNow Alliance/Relationship manager and these Instances can be used only for Dev. work for major Releases, these can be kept as separate from the Instance on which maintenance/minor release work is done.

Regards,

Mishu

Note: Please mark this response as "Helpful", if in case it has resolved your query. 

[cmsrenaski]

Thanks, Mishu

We capture everything that we can in update sets, but there are a lot of things that don't get captured in update sets. We like the idea of getting another sub-prod instance for longer-term projects. That may be the best approach, but it will be an investment that will need to be approved. 

Thanks for all your help!

[huntj06]

I'm currently working on a long term project and ran into this exact issue. We're implementing the HR onboarding module and like you said, since this isn't in prod it's hard to exclude the data from the clone. I just actually enabled the module in prod and moved everything but disabled the creation of onboarding cases so when we clone I'll still have my work saved. 

I do like the idea of backing up the update sets/etc. But sometimes, things do not get captured and theres a good chance you will miss something. 

In this project I was working in 3 different scopes, so I had update sets everywhere and just didn't feel comfortable using the backup method. 

[cmsrenaski]

Hi,

huntj06

Thank you for your input. I am so glad we're not the only ones that have experienced this. In our case, we are trying out the Project Portfolio Suite and had the same idea of turning it all on in PROD but not giving out the licenses yet. Unfortunately, when we talked to our rep that was discouraged. They wanted to start charging us for licenses as soon as we turned it on in PROD. So, we're looking for other avenues...

Thanks again for confirming we're not alone...

[Sabrina10]

Have you tried engaging with ServiceNow to see if they'll give you a 4th instance for long term POC projects?    I've had several customers that have had a sandbox instance where they do POC projects to avoid disrupting the normal development cycle.