Versioning and parallel development streams for worldwide SAP roll-out

[Former Member]

Hi SDN folks,

My customer is in the process of a worldwide roll-out of SAP. They have a transport environment for ECC that looks like this:

D -

---

> QA -

---

> R -

---

> P

We have SAP Charm installed and running in solution manager - to manage the creation of transports in the D system.

The problem we are facing is how to manage parallel development changes and configuration changes.

For example - if we have developers working on a change that is in test in the QA environment - and we hit a production emergency in P - we then need to make an emergency change to the P version (which would only be available in P and R) - and transport this change through to P - in the process - overwriting the changes that our developers are working on in the D and QA environments.

We also have the issue of objects for multiple countries being developed and configured in parallel - and so there will be version conflicts up the to the QA system as well.

Is there any kind of solution for the management of parallel development streams - and versioning - for all custom code / development objects and for configuration changes(other than introducing a second development system)?

Is there any kind of 3rd party product for SAP that helps to solve this issue?

Currently we are considering development freezes, manually renaming objects with versioning identifiers (will only work for some objects), manual backups of versions. - none of these seem to be a tidy universal solution, is there one?

Any help / directions you can offer will be appreciated,

many thanks,

Julian

[Former Member · Accepted solution]

Hi Julian,

I think you should seriously reconsider your current setup, as you are in high risk of systems getting out of synch.

>For example - if we have developers working on a change that is in test in the QA environment - and we hit a production emergency in P - we then need to make an emergency change to the P version (which would only be available in P and R)

This is condisdered a cardinal sin. No matter what, objects should NEVER be changed in P. ALL objects should be created and maintained in development. That is the whole point of D and P in the first place, and it is a rule that should be strictly adhered to above all others (unless directly told by SAP Support).

In your situation, you can have developers save their current development in released transport requests, revert the object in D to the P version in a new transport request, fix the object in D and promote it through the lansdscape to P. Then, developers must merge their development in D with the production fix. They will have their current development saved in a version.

>We also have the issue of objects for multiple countries being developed and configured in parallel - and so there will be version conflicts up the to the QA system as well.

If you have confilcts, though, how are they handled in P? That is, P only has one object for all countries, correct? How are you developing for multiple countries in the first place?

Best Regards,

Matt

[Former Member · Accepted solution]

Hi Matt,

I think you missunderstood my post - as it wasn't clear - appologies. When I said we need to make a fix to the version in P - I meant - but didn't state - that we would then need to make that change in D - and take it through our landscape - but this will then run into the problem of overwriting the ongoing developments that we have in our D and Q systems. We don't want to slowdown our ongoing development efforts - and we need to do the production fix. We have absolutely no intention or proposal to open up the P system (or even the Q and R systems for that matter - for development). We have a strict policy of all developments proceeding from D to Q after unit testing - and then to R and to P.

The problem is how do we manage parallel developments to the same transport objects - and how also do we manage parallel configurations? I don't think standard SAP can support this as its version management is not powerful enough, I'm hoping I'm wrong though.

[Former Member · Accepted solution]

Hi Julian,

Thanks for the clarification!

Managing production support and new development after go live is always a challenge. It can be addressed in many ways, but it is most important to create a set of rules and stick to the procedure. If you do not want a "second" landscape, you are going to have objects "overwritten" in the D and Q systems when you need to make a production fix -- as you must revert the object in D to the P version to make the fix. Even with a second landscape, objects will have to be merged somehow when a fix is promoted to production.

As I said above, what you can do is have your developers save their current development in released transports before making the production fix. This saves a version that must be merged with the fix, anyway. That is:

Object A is the produciton version and must be fixed.

Object A' is the current development version (unfinished) and is saved into a released transport request.

In D, Object A' is reverted to the A version and corrected for the production error, creating object A'' that is promoted to production.

Object A' and A'' are manually "merged" into A''' as the new current development version.

Yes, objects are overwritten with this method. However, you can always retrieve what has been overwritten since it has been saved in a released transport.

Another option is to bypass Q for production fixes. I.e. D -> R -> P. However, this invalidates the objects in Q until the merged version is created in D and transported to Q.

In any method you choose to do this -- dual development landscapes or not -- discipline and managment are a must.

Best Regards,

Matt

[Former Member · Accepted solution]

Thank you Mat, your post confirms our thinking - and helps us proceed with more confidence with the transport merge solution on release from the D environment. We have had a written proposal from a third party suggesting to transport 2 versions live - both the old version with production fix and the new (project) version (it seems to be light on the details of when to merge the changes), and then remove the old version after 15 days - but I cannot possibly see how that would work for things like user exits and enhancements - where there are common sap objects - plus it would be extremely risky due to having an "incorrect" temporary version live in production, so I plan to follow your suggestion - and not the 2 versions live solution.

many thanks for your thoughts.

Regards,

Julian

[Former Member · Accepted solution]

Hi Julian,

Unless the objects have different names, I would have them explain to you how two objects with different versions could be "live" at the same time.

Best Regards,

Matt

[Former Member · Accepted solution]

Hi Matt,

yes they are suggesting a rename - but that will only work for simple developments for certain types of object -

one exception that I can think of - is I can't see for instance how they can rename MV45AFZZ very easily without copying and renaming all components of SAPMV45A. Central user exits are common places to require fixes.

another exception - if there are 2 live version active for a program - which is expecting a database table to have a certain structure - and the other version is expecting a different structure - this means we will need multiple database tables active - and that would mean data conversions just for when we do the 15 day deletion.

I expect there are other instances where the approach will fail, especially for complex changes where there are multiple object interdependencies - and so I think I will put forward that it is not a viable alternative. Also I inherently don't like the idea of having 2 versions of the same program live at once. If a problem occurs in the production system - it maybe impossible to tell which version was the root cause.

This leaves us with either dual track or release control (as you proposed) from the development platform as the viable (and safer) alternatives.

thanks again for your help.

Regards,

Julian

[hardyp180]

Many companies have this problem i.e. more than one development environment.

The 3rd party company RevTrac have a tried and tested solution for this.

Specified objects can be locked so that only one development stream can mkae changes at a time and the other cannot touch them until the changes are finished i.e. in production . At that point the changes cna be automatically propogated to the second development stream prior to unlocking the object.

Cheersy Cheers

Paul