Versioning and parallel development streams for worldwide SAP roll-out

Question

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

Answer 1

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