Dual Landscapes and ChaRM Retrofit

[Former Member]

ChaRM Experts ... I am hoping you can shed some light on whether Retrofit would be better than how we're doing things now ...

Please bear with me while I explain our current landscape.  I will use ECC as my example, but we are using individual projects in ChaRM for our different technologies (CRM, PI, GRC, etc).

We use two landscapes for our monthly releases.  Our enhancements start in our project support landscape, which is configured like this:

DEV --> QAS --> PPD

We do development & configuration and unit testing in DEV (using ToCs) using Normal ChaRM documents, and then release the transport to QA for our UAT.  Once UAT is completed and approved, we move the corresponding ChaRM & transports into PreProd.  Here we do regression testing and validations.  At this point, we approve our ChaRM documents to "In Cutover" status.

This is where it gets messy ... from here, we create an Urgent ChaRM document for deployment to PRD, which is in our Production Support landscape, shown here:

DEP --> QEP --> EEP

In the Urgent ChaRM document, a developer creates a workbench, customizing and a configuration transport.  Then the developer "bundles" all of the workbench objects from the transports in the Normal ChaRMs from the project landscape into the workbench transport in the new Urgent ChaRM in the Production Support Landscape.  The same process is done for the customizing and configuration objects, respectively.

This works most of the time, but we have run into unexpected object conflicts when doing the "bundling."  This can take a long time to find the culprits, especially when there are 60 or 70 transports in the Normal ChaRM documents from the Project Support Landscape.  It is a tedious task, but when it works, the best case scenario is that we have one Urgent ChaRM to move forward into PRD for the release.  Sometimes we end up with more, but typically we are able to keep it under 5 Urgent ChaRM documents.

One of my concerns with this method is that we do validations in PPD, and then move the changes into PRD using a different type of ChaRM.  I feel this is a risk, but this is what SAP recommended.

Another concern is the traceability of the objects back to their original transports.  There are two aspects to this.  First, our developers would need access to some sensitive transactions in PRD in order to verify the objects, as there would be no way to "see" their transports in PRD.  Second, auditing by object may be a painful process.  If we're asked about specific transports in the Project Support landscape, there is not a 1-for-1 transport relationship in PRD. 

So, with that background, would retrofit be a viable method of creating 1-for-1 ChaRM documents and transports in the Production Support landscape, so we do not lose that relationship?  Would it even make sense to do this?  Does staying with the "bundling" process in Urgent ChaRM documents make more sense?

I do see where retrofit could be a benefit in the Production Support landscape, in that if we have any urgent break-fixes, we can manage object conflicts under development in the Project Support landscape.

I hope somebody here has dealt with this, or a similar, situation.

Any advice is much appreciated.

Cheers,

Scott

[rishav54 · Accepted solution]

Hi,

Yes, Retrofit can help you here.

Configure the Retrofit as

N+1 DEV->QAS->PPD

N-> DEP->QEP->EEP

Now create the two logical components and include in the same project. Configure the DEV system as retrofit system, now you need to create the transport routes from PPD to DEP and I hope domain link should be defined already and CSOL you need to configure. When you will be creating the transports from DEV system , it can be forwarded to DEP,QEP. You have to define the target systems accordingly.

One more thing you need to take care of auto-import job that you need to schedule it carefully as to which systems you wanted to perform the test.

This way you have 1 to 1 mapping and you can reduce the risk and you can trace the changes very well. Give a thought.

Similarly other way around, when you will be creating any transport in DEP, you can retrofit to DEV.

Regards

Rishav

[bxiv · Accepted solution]

I'm also confused on why your developers would need access to sensitive transactions in Production?  SolMan has tools to report on transports through the landscapes that it pulls from the remote systems, along with other specific tools to verify object versions within transports between various systems (however object verification is not real time and will take time to setup/run).

[Former Member · Accepted solution]

Bill -

Thanks for your feedback.

We have many contractors that have been given somewhat restricted access in our systems (not my decision).  What they are used to doing is going into the Project Support DEV systems, going into SE09 and drilling down into the transport logs to see that their transports are in PRD.

Since we create new transports in the Production Support landscape and bundle all of the objects from the Project Support landscape Normal ChaRM transports into new Urgent ChaRM transports, the visibility to see the original transports in PRD is gone.  The only way to confirm the objects from the original transports is by having developers log onto PRD, and use SE80, SE38, SE16, SE37, etc ...

One thought is that this could be resolved by allowing our developers to use FF IDs during the release to do the object validations.

Scott

[bxiv · Accepted solution]

Config Validation is going to be useful, its not the easiest to setup to start off with however once its setup its a bookmark for users to quickly pull up where transports are in the various systems.

I used this method to identify transports that made it to QA but had not yet gone to Prod (due to a system refresh); this also provides how long a transport sits in the system before being transported along with other various timestamps.

[Former Member · Accepted solution]

Rishav -

Thank you very much for your input.

It is good to know that what I was considering is possible.

Scott