Current position:  Home > Default > ABAP Software Logistics

ABAP Software Logistics

Time:November 30
Advertisement
Hi all,
at my company we are responsible for maintianing a growing number of customer SAP systems. While focussing on the same application area (i.e. utilities industry) all these systems differ with respect to customising und custom development.
In order to simplify maintenance of the different systems we use a central development system to develop common business functionality (development is performed in our own name space). The developed code ranges from simple reports to complex packages with dependencies onto other packages. The standard SAP transport system is used to distribute the code to the customer systems.
Currently we have the following challenge. We perform bug fixing and developments of new features in our central development system. After that a new version of a report, class or even a whole package is transported into one or several customer systems. However, due to different testing cycles and requirement, we almost never have the same version of a given development artefact in all customer systems. This makes bug fixing and implanting new features terribly difficult. If we need to make any changes that are not backward compatible, chances a high, that future transports cause problems in the customer systems.
What we would need is the possibility to define a "software product". This would consist of a set of development artefacts (e.g. the contends of a package) and should be versioned. This would allow us to keep track of the versions available in the customer systems. Furthermore, the possibility to have a trunk an several branches of some development artefact would significantly simplify the problems we are currently facing.
Are there any best practices or maybe some third party tools that solve the issues mentioned above? Does anyone here face the same issues?
Thanks for you help in advance,
Christian
Advertisement
Transport and change management is planned for version 12.1 next year because we needed some additional functionality that is found in NW 7.1, but was not available in 7.0 (2004s).  This was originally intended for 12.0, and may be why the docs are a bit misleading in the statement you quoted.
Your options for content and configuration backup and transport from system to system are really done by the two options on the System Administration section of the admin Menu.  Projects are exported/imported from a single zip file archive and the supporting Configuration options for backup also create a single zip archive for backup and transport. 
Udayan mentioned the Workbench editor for import/export, which is true but typically for smaller sets of file(s).  The Project screen provides a very convenient manner for backup and transport.  When a project import is performed it does an insert/update approach, so for a complete system mirror it is best to delete the existing project and then import the updated project fresh - this will make sure no removed files are leftover from a previous deployment.
Regards,
Jeremy