Custom code synchronisation across the SAP landscape
They tell me it’s not uncommon, for example, for someone to have broken into PRD to make slight change to an object and then forget to replicate this back in QAS and DEV or for an object to make its way to QAS and for some reason get stuck there.
Good change control process and automated change control technologies can certainly help manage the flow of objects from DEV to PRD in an orderly sequential manner and so is a very good place to start. Change control ensures there is a process around making changes, the workflow and approval requirements for each and so makes an immediate difference to the quality around object version control.
What about the current state of play though?
Although object version information is held within SAP in various places, unfortunately there are not a lot of technologies available that enable developers, team leaders or project managers to quickly get at this information to compare versions and make decisions accordingly. The amount of times one comes across an object version spread sheet or an access database as a version control method, even for extensive and complex SAP environments is surprising. The problem with this is the database or spread sheet accuracy relies on human discipline and so comes with no guarantee of accuracy.
What is required is a tool that allows you to easily, simply and very quickly compare custom objects across multiple SAP systems allowing project team members to quickly see which objects are different in DEV, QAS and PRD and then to drill down to see just what these differences are. Such tools will provide confidence (or not) in existing change control procedures as all differences should be accounted for by a good change control technology.
The good news is that technologies are being developed by third party software vendors to assist with this type of system and object version visibility. Keep an eye open on the SAP EcoHub, TechEd exhibit halls and vendor promotional materials and searches using terms such as “SAP custom code version tools” should throw up a range of options for consideration.
But then, breaking into production as you suggest is highly controlled and would never result in a discrepency between prod and dev in the way you describe.
What is missing in the built in, however, is that you can't check a whole class, or function group easily. You have to check each method, on its own, then the private/protected/public sections.
matt
Regards, Rick
- test import (find import and activation errors before actually importing)
- undo (backout a transport by automatically resetting all objects to previous version)
- overtake check (prevent older, unapproved changes surfing into production along with newer, approved changes)
Can I have these, please? 😉
Thomas
Good change control process should virtually eliminate the need for an 'undo' one would think? I believe that, at this point in time at least, that SAP do not support the concept of undo. There is a SAP note to this effect - its quite old but I don't know af any later notes. Perhaps some else does?
I believe CTS central will have some kind of feature around this when available. Overwrite and overtake checks are avaialble in in add-on change control technologies but not in CTS just yet.
Regards, Rick
I meant to say that CTS Central wil have something along the lines of an overtake check.
Regards, Rick
SREPO transaction is a powerful tool that gives you an overview of different objects/sources, though it doesn't give you access to the detailed differences (you have to access the versioning tool of each object to run the individual comparison)
I also provided a "transport simulation" program in the wiki section of SDN, it can be very useful for situations of missing objects in the target system.
I'd love to have a tool to restore or compare version in mass, by transport request especially.
I don’t want to come off as being too critical, but unfortunately It does look like the developer got pulled off the project before they could get to the good bits 🙁 notice how there are no dropdowns on selections, German messages and also an inability to drill down to see if or what the actual differences are - or even copy and paste the object names into the needed alternate session editor.
Another limitation I found during my exploration was that transaction SREPO only considers Y and Z objects to be customer owned , this maybe a problem for some of the larger or more progressive companies using the newer namespaces such as /xyz/.
If you like what you see in transaction SREPO, I suggest you take a look at the free apps in Salt (saltapps.com) especially the Matrix app - it allows you to compare whole landscapes simultaneously, drill down and also analyze the new namespaces (without the long wait), it also provides the transport information and relative versions so that you can see why the difference is there and what to do to fix it.
Cheers,
Dave