What environment should I start implementing in? Prod (then clone down) or Dev (and move up)

Winston
Tera Guru

Hello everyone, 

We're going to begin implementing our system soon, and I was just wondering what's everyone's take on this is. Servicenow on the ITSM Guided Setup recommends that for new users to start in prod and clone the system down to test and dev. I've always done work in dev environments then moved up, is it possible to clone a prod environment after a test or dev environment?

1 ACCEPTED SOLUTION

Allen Andreas
Administrator
Administrator

Hello,

I've done 3 implementations and 2 of them I've started in Dev and went up...the last one I did in Prod and went down. The "normal" development methodology as far as starting from Dev and moving up doesn't necessarily apply when starting brand new.

Personally...either way is fine, but the benefit of doing things in Prod is that you get to build everything exactly how it should be for production, settings, etc. Then once you're done, you can clone down to the sub-prod instances and make any cosmetic tweaks, etc. for those instances. The benefits here is that you aren't relying on cloning to bring that information forward and with exclude and/or preserve settings set...those clones could miss bring up certain things from the lower environments. Also starting in Production gives you a very bare instance, which avoids all the demo data and settings and allows you to clone that information down so that your sub-prod instances also don't have this.

If you do decide to clone from a sub-prod to prod, you will need to set this system property to "true":

glide.db.clone.allow_clone_target

however, once you're done...you will want to immediately set it back to "false" to prevent any sub-prod instance from accidentally cloning over production.

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

View solution in original post

7 REPLIES 7

Anil Shewale
Mega Guru

Hi

As this is your first time going to production I would use the clone method followed by a request to clear the sample data from production.   You'll want to check carefully any integrations you have once they are cloned into production to make sure they still work.   One common reason for issues here is if your integrations pointed to your development instance URL, the clone will carry the same URL into production.

 

An alternative method you could have used back on day 1 is to do all of your development in the instance that would become production.   It's not really production yet since you don't have users conducting business there.   Then you know all integrations work with your production instance URL.   Once your "flip the switch" and start using the instance you then clone from production backwards to test / development, and from that point moving forward use update sets from development to test to production.

The most important thing that we need to do before the clone is to take backup of all your update sets which are on development instance but not on prod.

Close all our update sets on dev and retrieve all these update sets on prod. Do not preview/commit these update sets on prod.

Clone your instance to Dev. Now commit these update sets again on Dev.

 

If it help mark helpful or correct 

Thanks and regards

Anil

Ashutosh Munot1
Kilo Patron
Kilo Patron

Hi,

This depends some factors where to start with:

1) If you are the new customer and you don't have done your go live then go for production instance.

2) If already Go-live is done then we always do it in sub prod instance and then proceed further.

 

So You have to make a choice, ServiceNow has mentioned it clearly.


Thanks,
Ashutosh

Jan Cernocky
Tera Guru

If official SNOW guide suggest you something you should go that way.

On the other hand, If I was starting again I would probably still keep the DEV > TEST > PROD cycle, because:

- development wil produce lots of testing data that may not be easily wiped out by "remove demo data" feature, that is definitely not something you would like to keep in production

- development produces also lots of logs, history, audits, etc. that are not desired in production

- you may get familiar with the process of moving update sets from one instance to another if you are not used to do so

And I believe there will be more.

Allen Andreas
Administrator
Administrator

Hello,

I've done 3 implementations and 2 of them I've started in Dev and went up...the last one I did in Prod and went down. The "normal" development methodology as far as starting from Dev and moving up doesn't necessarily apply when starting brand new.

Personally...either way is fine, but the benefit of doing things in Prod is that you get to build everything exactly how it should be for production, settings, etc. Then once you're done, you can clone down to the sub-prod instances and make any cosmetic tweaks, etc. for those instances. The benefits here is that you aren't relying on cloning to bring that information forward and with exclude and/or preserve settings set...those clones could miss bring up certain things from the lower environments. Also starting in Production gives you a very bare instance, which avoids all the demo data and settings and allows you to clone that information down so that your sub-prod instances also don't have this.

If you do decide to clone from a sub-prod to prod, you will need to set this system property to "true":

glide.db.clone.allow_clone_target

however, once you're done...you will want to immediately set it back to "false" to prevent any sub-prod instance from accidentally cloning over production.

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!