Client Clean Up in our DV1 system

[laurie_mcginley]

Briefly ECC 5, Windows 2003, MS SQL Server 2005

u2022 DV1:100 u2013 Not being used or updated with transports u2013 so config not happening here, has old config data, out of sync.

u2022 DV1:110 u2013 Still is development u2013 abap u2013 programming area. Transports from here go to QA1:100

u2022 DV1:120 u2013 Currently being used for config changes. Transports from here go to QA1:ALL and if they remember to ask DV1:710 u2013 Currently testing only near as I can tell. Possibly not all config changes have been transported here. Some changes done here and transported from here.

u2022 DV1:710 u2013 Testing, has been refreshed from client copy from PR1 a couple of times.

*The issue: *Planning an upgrade to ECC 6; also just need to get a better handle on the clients in our system. Client 100 (the "golden" client) has not been used as such and is now out of sync.

I'd like to get back to a scenario where the we are more standardized and have fewer clients.

Ideally I'd like 100 - golden, 110 - abap dev, 120 - config sandbox, 710 - testing

I don't know at this point how to get client 100 back to a "golden" state. I have a good understanding of how to keep it there once done.

Is this something I should be concerned with - making/keeping 100 golden? Or should I pretty much write it off as an out-of-sync client and start using the 120 as "golden" and create a new sandbox for testing config changes?

Your suggestions are welcome!

Laurie McGinley

Edited by: Laurie McGinley on Aug 9, 2010 2:46 PM

[JPReyes]

Hi Laurie,

A "golden client" is basically the client that contains the version management and is basically the history of your system development, as per the info you gave us thats somewhere between 110 and 120.... as 120 is the one you use to distribute the changes to the rest of your landscape, most likely is the most suitable. 110 is possibly used for unit testing.

About 100, seems like this has not been updated and doesn't contain critical developments, if thats the case I would just get rid of it. 710 is posibly used for volume testing, if thats the case you are much better of having a sandbox as copy of PRD and use a delivery route to keep it up to date with developments and refresh it every so often.

That leaves 110 and 120.... which is more manageable.

Thats my 2 cents.

Regards

Juan

[laurie_mcginley]

Thanks for your quick response Juan. I was wondering about abandoning 100, but didn't know if there was a problem with doing that or not. At this point it makes more sense to do that, and "logically" think of 120 as our golden client.

We do have a separate sandbox system, mostly have used it for testing notes, patches etc. If it is a better plan to do config changes in a sandbox, I could open it up for our business experts to do that, and then use 120 for the final changes. I suppose I could even create a sandbox client from 120 now and mark it as initial config testing.

Actually, most of what they are doing now is more code changes, adding codes, etc, rather then config/customizing that changes functionality. I'm not so worried about them continuing to do that in the 120 client.

So in our DV1 system, I may go with:

110 - Abap dev

120 - config "golden"

710 - volume testing (testing with data)

our Sandbox system - refresh it from PR1 for functional config, patches, notes, etc

Does that make sense?

Thanks

Laurie