Pros and Cons of shared DEV client for Maintenace and Release

[Sajid]

What are pros and cons of using a single DEV client for both production support and new releases?

More specifically:

We are planning to use single DEV client for Production Support as well as new Releases (NO dual-track or N+1 landscape). This is a global phased roll-out by business divisions. We have a simple ECC landscape eg. DEV - QAS - PRD. We are planning to achieve this as below:

DEV-100 will be used as shared development client for Maintenance and Release activities. We will create two IMG projects in DEV-100 and  two consolidation routes/target using transport layers ZDEV and ZIMP: An IMG project will be mapped to respective transport route and enforced using custom logic at the time of transport request creation so that Release related changes do not end up production support clients. The routes will look something like this:

Route #1 : DEV-100 -> QAS-100 -> PRD-100 (Maintenance stream)

Route #2 : DEV-100 -> QS2-100 (Release stream) -------> PRD-100

There will be surely some overlapping between the two development streams which we plan to handle using version retrieval method or manually (for customizing).

What do you think of this strategy and the challenges/risks associated with this approach? Shall we be looking into a dual-track solution? Any assistance, advice, guidance or real life experiences with this would be truly appreciated.

[Former Member · Accepted solution]

I would recommend a dual track solution . It might be ok if your project is really small but when projects grow big its impossible to keep track of changes manually.

Biggest risk i can think of is , say your project is still not live yet but something is broken in your production system. If the same object is being modified under your project then it will be really difficult to fix your production system and might take longer.

when our implementation projects grew bigger and spanned multiple years , we were left with no choice but to have multiple development systems. We use Rev-trac to track object locking between two dev systems.

Regards

Amit Padmawar

[Sajid · Accepted solution]

Thanks Amit,

We decided to go dual track. One more question. How does Charm compare to Rev-trac in terms of implementation efforts and ease of use? Which of the two has less learning curve for the users after it is installed/configured.

Regards

Sajid

[Former Member · Accepted solution]

For revtrac

1) There is a licensing fee associated with it as its a third party product .

2) For implementing it , we had to bring in rev-trac that was almost two years ago.

3) Maintenance since then had been really easy.

4) Developers were able to adopt revtrac pretty easily .

For Charm

1) We dont have CHARM implemented but we are now planning for it , as it has more to offer.

2)  It will be free

3)  Implementation of charm can take you significantly longer.

but looking at what SAP now a days is putting into solution manager and its relevant modules , CHARM is a much better approach.

Regards

Amit Padmawar