Sandbox policy?

[former_member192129]

Hi.  Can you share what your company policies are for sandboxes?  Back in the day, we were supporting some 20+ sandboxes.  In total, the costs really added up.  So, we decommissioned many of those.  The usage was generally low.

We are now being asked to reconsider, in the name of innovation.

The policy I am putting forward is that sandboxes can be put in place in support of a project.  With a defined start & end date.  That way, we encouraged focused use of them.  And, it better allows us to redeploy hardware, and not carry ongoing cost.

What's your policy for sandboxes?  Better yet, do you have a document you can share?

thank you.

[Former Member]

Hi Steve,

As Graham has already metioned, Have you considered to use a Cloud model for Sandboxes (IaaS)? I mean, as the Sandbox environements usually have a limited used and they are used in a very limited time make a lot of sense to go for a Pay per Use model environments.

E.g. Amazon offers this service (AWS), here you have a link with a study:

http://www.publicserviceevents.co.uk/wshop_pdf/lg11_amazon_infrastructure.pdf

Regards

[Former Member]

Hi Steve,

I generally start out with a sandpit client per system for play config.  Thereafter I create a sandpit system per landscape so that they are in sync.  If you really want to go for it, then see if you can go to something like Amazon (AWS) if you are on Linux/Windows.  That way you can build the system and run it only  when they want to start it.  Thereafter you shut the system down as you only pay for storage of the data and pence per hour when you run the servers. 

Regards

Graham

[Former Member]

Hi Steve.

In our case we have one sandbox for each landscapes. By landscapes I mean the entire DEv, qa and prd setup for BI, ECC, SRM, CRM, etc. These sandboxes have the same hardware configs as the development, that is, memory, app servers, etc (just to reduce the cost).

Now, you can keep a sandbox for a lifetime because the use of sandbox is much more than project deployments. You can test various bug fixes, notes, coding changes, OS hotfixes, etc from time to time before going in to Prod or even the Dev.

As mentioned by Susan earlier, we also keep our Sandbox almost up-t-date with our Prod by refreshing the same periodically. Generally we have a frequency of half-yearly refresh but some landscapes have anual refresh strategy aligned.

Thanks

[Former Member]

We have 6 sandbox systems distributed distributed over 3 servers (2 systems per server).  The configuration/development team has to duke it out amongst themselves which one is used for what purpose.  I (Basis) stay completely out of that discussion other than telling them that they can't get any more sandbox systems.  But I also try to be very flexible and responsive when they want/need a sandbox refreshed from production.  Those requests have to come from the team leader or be explicitly approved by all team members.

After a refresh, they have the option to have the sandbox configurable, but in that case the system will not receive any transports other than patches from SAP or vendors, and any transports generated in a sandbox will never be exported or imported anywhere else. 

If they choose to have the sandbox not configurable, i.e. locked down like production, then they can request any transports from development they want to be imported into the sandbox.

Hope this helps.