three or four systems landscape with open customizing in testsystem

[frank_wagner2]

Hello,

I'm currently asked by a customer to recommend a way to handle their system and clients. This customer has a large number of clients in development and test system and also use systems like portal, BI and CRM. The clients in development are used for long running project purposes like master data migration development and testing.

I'm currently thinking about a solution to reduce the number of clients where the customer use 2 systems for development:

- new developments and project customizing in DV1 with 1 general sandbox and 1 sandbox for master data migration

- changes and fixes of implemented customizing or programs in DV2. This system is also used as pre-testing for DV1. All subsystems like CRM are connected to system DV2 and this system contains only 1 client.

So transport would look like this: DV1 -> DV2 -> PROD

Of course I know the problem of missing transports and settings so I would recommend a four system landscape: DV1 -> DV2 -> QA -> PROD or DV1 -> QA -> DV2 -> PROD.

The obvious drawback of this solution is that when DV1 changes are transported to DV2 no more correction can be done for production. But that's same when you have just one development system.

So I would like to ask you, if you have some ideas about other issues when using 2 development systems. I'm also wondering if really every customer keeps their test system closed for changes.

Regards,

Frank

[Former Member · Accepted solution]

It's our inhouse rule that if you have 1 PROD, then you have 1 DEV. Because if you have multiple DEV going into a PROD, eventually you'd need a consolidation point somewhere. So, we have decided that all changes going into DEV must work together right-off-the-bat.

[frank_wagner2 · Accepted solution]

Hi,

yes agreed, but consolidation would be done in DV2. And of course that means that fixes have to be done twice, one time in DV2 and than in DV1.

Regards,

Frank Wagner

[Former Member]

Hi Frank,

How about having the landscape like this:

Main line: (say, Production line)

DV1->QA1->PROD

Second line: (say, Development line)

DV2->QA2

DV1 - For changes and fixes of implemented customizing or programs in DV2

DV2 - For new developments and project customizing

First you will do the developments / project customizing in the DV2 and test them in QA2. If successful, have a synchronization or Merge between Dv1 and QA2. i.e, successful Developments and customizing will move to Dv2. If any changes / fixes required .. you can do them in Dv1 and send it QA1 for testing before you move them into production.

Experts - Any other strategies comes in mind? Do you see any complexity in the above mentioned landscape?

Regards,

Srihari