Preserving ServiceCommunity integrity in Dev and QA

[Emir E]

Preserving ServiceCommunity integrity in Dev and QA

RC 2006.0.7

Many of us have issues with keeping our Prod, QA and Dev insync.

Here is an approach I am thinking about implementing and wanted to get everyone elses opinion.

Keep Prod as is. Lets say current person/queue sid is 35000. I would extract sid 35000 from Prod, modify the dar file to change the sid from 35K to 35000000.

In Dev now the highest sid is 35M and the nest auto generated id (SSO, LDAP) would be 35000001 and so on. However moving the next queue from Prod to E1 might bring it in to 45000 range, which is fine as Dev would not have that sequence and there would be no collision till it hits 35M. The ongoing queue migration would go BAU.

So the issue is what happens when Prod hits 35M, but realistically before we use up 35000000 licenses this system would be outdated.....

 Any feedback?

[Emir E]

How about this one?

Create 1000 sequential queues in Prod. Use them as place holders for future use. Let Dev and QA run their own sequences... If I ever run out of, I repeat the same excercise ....

Any suggestions?

[Tylor Hagerman]

Hopefully the newer versions of RC will use GUIDs instead of sequences, making it irrelevant what environment an object was created in.  Its too bad users are having to go to so much trouble to keep everything in sync.

[Ken Komara - Allstate]

When we are ready to begin testing a release, we backup the production database and refresh our test server with this backup. This brings in both the ServiceCommunity objects as well as existing requisitions which we also use in our testing.