Doubt in SAP Transport Strategy

[former_member185954]

Hello,

I am designing a landscape strategy for my clients, wherein they are supposed to develop a double track (near parallel) development strategy for my clients.

The client currently has 5 system landscape, where in the transport follows in this manner.

DEV -> QAS -> UAT -> TST -> PRD

They perform development in stages, just like SAP Release strategy.

However in this strategy , the quick fixes, RFCs (request for change), support issues are not handled or are delayed.

So they wish to have a landscape which supports projects as well as support both happening at the same time, independently.

I am suggesting them a strategy as per the diagram given in this link below.

http://www.geocities.com/siddhesh_ghag/landscape.JPG

The whole idea is pretty simple, i.e. to copy the DEV and QAS into DE2, QE2 and then periodically refresh support systems with the project systems.

The question here is that , i am converging my support and project transports back into UAT.

I don't recollect, however I think there is a problem around transport layer and that i can have only one development track..

I want to know if this is possible, are there any limitations / concerns around this.

Regards,

Siddhesh

[former_member185954]

Thanks for your time.

[former_member185954]

pushing the question up in the queue

[Former Member]

Hello Siddhesh,

Off the top of my head, consider this scenario:

You develop object X in system DEV.

You then make an urgent fix/bug fix/whatever to the same object on system DV2, and it asks you to enter a repair key!!

Of course, this is doable, by getting a key and entering it, and then when transporting it, using an unconditional mode to "overwrite originals".

In our project a similar solution was proposed, but we ended up developing both "major" projects and the bug fixes on the same system, working carefully that those two do not inter-depend.

However, if you do decide to go about developing (the same object) in two (or more) systems on your transport route, you'll always end up "repairing" them on one system (the one where it didn't originate).

A bit of a better solution, would be to develop the new project in a separate namespace on one system, and to move the older projects to be patched/fixed exclusively in the DV2 system, by changing their original system, and never touching them again in the DEV system.

Like this:

-

---

-

---

| DEV | -

---

> | DV2 | -> QAS -> etc.

-

---

-

---

/NEW/ /OLD/

(The /NEW/ represents the new project, the /OLD/ represents the old ones, with namespace separation and protection against accidental change).

A variety of this would be to develop in both system, separating old and new developments, and both "feeding" the QAS, etc. systems. This is possible with two separate transport routes (just like the customer route and the SAP standard route which all of us have in our landscapes...).

Hope this helps.

Daniel

[former_member185954]

Hi Daniel,

Thanks for your reply, however for me namespace is not an option, since we are working on improvising the same objects in the each consequent release.

I figured out that if we can tie back all the changes from D2 to D1 and then create transport of copies to repackage the said transports (from D2) and migrate along the path of D1, it should serve our purpose.

Regards,

Siddhesh

[former_member185954]

On 2nd thoughts, we can also simply add to the transport queue the request from D2 as 'OTHER' request and carry out the import.

Regards,

Siddhesh