Using CHARM on a rollout project (Dual Track) issue with AM change & retrofit

[Siarljp]

Hi Charm experts everywhere!

We have implemented SAP Charm on our solution manager system, the motivation being to allow us to meet our audit requirements (for a multinational retailer).

As one of the development architects for my company, this has presented us with numerous development challenges.

Our company as a whole operates a more or less agile philosophy, and expects SAP to be compatible with this philosophy, and we have been struggling with this from a Charm perspective.

We have a dual track Landscape, so an AM line and a project line. Charm on the project line is setup to use transport of copies, and regular transports on the AM line.

A  - - >   C - - > P   (regular transports) transports are release in A to then goto C and P

D - - > T - - > Q - - > P (Transport of Copies) - Transports are only released when project reaches Q.

           Project 1 is in Q (and so in final testing)

           Project 2 is in T (and so transports have tasks released but the transport itself is not released).

The problem we have is that we have overlapping projects in the project line - as a result of the worldwide rollout. This means that we can have one project that is deployed to the Q system, whilst another is deployed to the T system. Then we also have the AM line for production changes.

Most recently we have had a developer needing to make critical AM fixes to complex code in production, this they have done (its a 4 line code fix). The problem has been with the retrofit. The objects in question were not changed in the project that has been deployed to Q (the next project to go live) - instead they have been changed in the most recent project - that is currently only in T, and the tasks have been released, This forces the retrofit changes to be placed into this unreleased transport for project 2. This will then lead to a downgrade situation when project 1 is deployed to production.

Unfortunately the changes that are in T in project 2 are very many and represent some major changes, with many interactions. So now to retrofit our AM request we are looking at needing to completely undo these complex changes. We are hoping that there maybe another alternative, but currently it appears that our only other option is to let the code downgrade with our next production release, and then to apply an emergency AM to correct the situation shortly after. Is this the correct approach? Is it our only option (apart from undoing our changes)? We are considering improving our work processes to accommodate for this issue, although its not that clear to us what these improvements should be... You kindof need to anticipate where your AM issues will be ahead of when they occur (if only we had a crystal ball!)

How do you manage / setup charm to work best in an agile coding environment?

Many thanks for your time and consideration in advance.

//Julian

[bxiv]

When it comes to dual landscapes, the best practice is to only provide new development in the second landscape.  The first landscape is in place as a support line for your Production system( s ), and should only have changes made to resolve issues that prevent lets say a sales order from completing, or an snote installation/update.

When the project on the second landscape reaches the project cycle after go live, its in your best interest to refresh the first landscape from the second (system copy, DB restore, TDMS, etc).  This is needed to keep all object versions in sync with that of Production, and prevent overtaker transports.

If we go back to the example of the snote scenario, at some point you have to retrofit that change to the second landscape in an open and waiting transport to be associated to a project that moves into production.