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