Full production refresh to development systems and Charm?

[Former Member]

Hi SDN Community,

Where I work we have a policy of refreshing the development systems (ECC, CRM, APO, BI, SRM) on an annual basis with full production system data, HR data is subsequently wiped clean from the development system.

For each of our systems we have a development system, a QA system and a production system.

The decision to do these full refreshes was taken to ensure that developers and configurers can do decent testing in the Dev environments - prior to transporting to our QA system - to ensure that we have a reasonably stable QA system. Prior to the refreshes - QA was considered too unstable by our business to be used as a good test platform - the full D refreshes solved this problem.

We have recently installed SAP Charm (Change request management) which is a solution manager based product that manages the transportation of objects in change requests - attached to maintenance cycles.

During our first development system refresh we discovered that all open Charm projects (maintenance cycles) were placed into an unuseable status due to the refresh. This means we had to rebuild all of the Charm projects after the refresh - which took a considerable amount of time + resources and delayed project work. We don't want to be in this situation again for our next refresh.

SAPs response to us has been that they have no other customer that does full Development system refreshes - and also has Charm. I wonder if this is accurate, I think what SAP are saying is that they don't have many Charm customers... Is refreshing Development so uncommon?

We are considering products like SAPs TDMS - and alternatives (eg gold client) - but most of these appear a little immature - for refreshing complex system landscapes - such as ours and keeping everything in synch after the refresh.

My questions to SDN -

What do you do - do you do full refreshes to your D systems?

If not - what are the arguments against refreshing D systems (is this considered bad practice)?

Are there any other Charm customers out there in a similar situation to us?

How do you manage the stability of your QA environments and stop the transport into QA systems of untested changes - if your D systems are not similar to you production system

(note we have some 300 active users in just our ECC development system)?

Any suggestions / recommendations as to how to best proceed would be greatly appreciated.

many thanks in advance,

Julian Phillips

Edited by: Julian Phillips on Nov 11, 2008 2:33 PM

[Former Member · Accepted solution]

Hi

Refreshing Dev Systems from Production is not very common

It is normally the QA systems which get refreshed from Prod ( monthly, quarterly , yearly, whatever suits your organization)

The primary reason for not refreshing Dev is that there are many actvive changes ( due to projects , production support etc) in dev which will be lost if it gets refreshed

Testing anyways can be always done on the QA box

[Former Member · Accepted solution]

Thanks Naushad for your reply,

I wonder if D refreshes are less common - more due to the additional hardware costs incurred (disk space needed to store full production data is usually pretty large) to do them - than due to avoiding disrupting development - probably a bit of both.

I did not mention this - but in our refresh we do reimport all transports that we open prior to the refresh - which used to solve our problems - in terms of restoring active changes - but with SAPs Charm system - this approach does not work as the Charm projects are left in an inconsistent status.

We are now leaning towards introducing a 4th set of systems into our landscape - so that we have the following platforms:

Development ---> Pre QA ---> QA ---> Production

This approach will allow us to keep both the Pre QA and QA systems refreshed every 6 months or so - and our new Dev system - we will refresh very infrequently (every 5 years perhaps) if at all. We will tie the Charm system to our new development - and this system will then not be impacted by refreshes. This approach means additional hardware cost - but as it happens we have a few spare boxes - so this maybe our best bet.

The core reason for our refresh is so that we will be able to preserve the stability of our QA test platform - which for us is the critical factor here. If QA has poorly tested work in it - we run a higher risk of disrupting other testing and also of this poorly tested work reaching production.

When we used to have a development system as you described and just the single QA box - we experienced frequent instability in our QA box - due to poorly tested working reaching it - and this delayed numerous projects.

Does anyone else have a 4 box setup like this? Anyone else encountered this on an SAP project anywhere? Pros / Cons of this approach?

//Julian

Edited by: Julian Phillips on Nov 12, 2008 8:08 AM

Edited by: Julian Phillips on Nov 12, 2008 8:18 AM

[Former Member · Accepted solution]

Hi Julian

I have also seen four box approaches, It all depends upon the resources the client has in terms of hardware availability and the effort required to refresh a system

If you already have the hardware available, than four box approach can be adopted.

The quetion to be considered is at what frequency should you refresh these boxes. A lot of it depends upon what is your release managment strategy.

A typical client than i worked with, refreshed this additional QA every night. The changes were first tested in this and than moved to the actual QA which was refreshed every month ( they had a monthly release cycle)

The only CON in the effort is the resources needed n terms of hardware no effort to refresh

Let me know if u have any questions

[Former Member]

Hi,

Just to add check SAP Note 130906 - How can versions be transported?

Also see below links.

Thanks

Sushil

[Former Member]

Hello Julian,

I face the same situation as you. We are working with ChaRM and we are thinking about refreshing development with production.

As I cannot test that, can you tell me what was the unuseable status of the project you were refering to ? Was the existing Maintenance projects reusable after some operations or did you have to create new projects ?

If you were able to use with the existing projects, what operations did you have to perform to make them work again ?

Thank you for your help.

Best regards,

Benjamin Rouger