Best Practices for Running the NWDI
The current NWDI landscape has grown out of the need to combine an existing production environment for Java development with the new component model concept supported by NWDI.
This paper contains recommendations about the setup of tracks, track landscapes, and development processes; these guidelines have been found useful and reliable for the software production at SAP.
The concepts presented here are documented in detail in the SAP Library for SAP NetWeaver (http://help.sap.com -> SAP NetWeaver Development Infrastructure).
Only use one NWDI for the development of multiple releases of software components (SCs).
Setup of Tracks and Runtime Systems
Track for Development of a New Release
One track is sufficient for the development of one release of a software component. It offers the complete production environment for all phases of development including the quality assurance steps that guarantee high quality software. The track itself is simply a logical container for organizing the development process in a structured way.
Recommended Use of Runtime Systems in a Track
Since the Change Management Service (CMS) of the NWDI enables you to attach up to four runtime systems to a track – one for each state of the software – the following use of runtime systems has proven itself as most effective.
- Runtime system ‘Development’: Immediate testing of the newest changes.
The runtime system in the development state is especially effective when it is combined with regular automated tests, for example an automated test that runs every night. In this way a lot of errors can be detected very early in the process. The overall quality of the software improves.
If you think that local tests by the developers are sufficient for the overall quality of your software, it is possible to omit the runtime system from the development system. The first integration test system will then be the runtime system of the “Test” system.
- Runtime system ‘Test’: Testing of consolidated software state.
This system offers a test environment for the software that mirrors the production environment.
- Runtime system ‘Production’: Deployment in the production system
Organization of the Development Process
The development cycles at SAP are managed in milestones and phases.
Milestones are software versions for which a certain set of software features must be developed.
Phases are the time periods in which the specific tasks for the milestone are carried out, for example, development, testing, and integration tests (MIT).
New milestones are developed in the development system of the NWDI track. This offers system offers an area for big structural or architectural changes and the development of new functions. These tasks are usually covered by the development phase.
After the development and test phase the software state is released and transported into the consolidation system, thereby performing a source code split.
This is to provide stable software and to offer an environment for small corrections. The development system and consolidation system are connected by retro-transports that allow to transport small corrections back to the development system and to avoid double maintenance.
The Development Process
The development of new milestones is combined with automated tests in the runtime system of the development state (DEV).
Corrections to the production state are done in the consolidation system (CONS) and are transported back to the development system.
The developers develop and test their new functionality in the local Developer Workplace. This consists of an SAP NetWeaver Developer Studio and a locally installed J2EE Engine. After the local tests, the developers check in and activate their changes. This triggers the central build in the Component Build Service (CBS) of the NWDI and the results of this build are deployed in the runtime system of the development location.
The runtime system DEV of the development location is the first environment for integration tests of changes from different developers.
The start of correction phase involves the transport of the milestone from the DEV to CONS. After that, corrections to the milestone are done in CONS. These corrections are transported back to DEV by internal back transports. The fixes made in the correction phase can be assembled and deployed in the test system until the quality of the software has matched the necessary criteria.
Handover to Production
After successful tests in the test system, the milestone is handed over to the production team that needs to approve it (Approval).
Deployment to Production
The production team defines and publishes a schedule specifying when the new milestones will be deployed.
Restrictions of the “Single Track Setup” Development and maintenance within one track are only possible as long as the production state and the development state are based on the same Support Package level of the SCs which are not developed in the track.
As soon as you want to start development based on a new Support Package and still retain the production system, you need to set up a maintenance track as described in Advanced Landscapes.
Recommended Steps on Developer Level
- DEV: When should I activate my activities?
Activate your activities after the following steps:
- Change locally in IDE
- Deploy on local test engine
- Check in and activate after successful local test
- DEV: When should I release a change request?
Release your change requests in the Developer Studio after successful tests (automatic tests) in the runtime system attached to the ‘Dev’ state. This will trigger the further transport through the landscape.
Recommended Steps on Administrator Level
- TEST: When should I import into the test system?
Import any software versions (Milestones) that require intensive testing into TEST. The advantage of using the TEST system instead of a runtime system at the CONS location is that the time the imports are started can be controlled exactly
- PRODUCTION: When should I import into the production system?
Import the software into the production system after successful tests in TEST guarantee an error-free production use of the software.
Tracks for the Maintenance of a Release
The maintenance of a release is supported by NWDI using a second track. A transport connection delivers changes from the development track to the maintenance track. A repair connection transports corrections made in the maintenance state back into the development track, thus avoiding double maintenance where possible.
For a detailed description of the maintenance scenario, see the SAP NetWeaver library: (http://help.sap.com -> … -> Application Maintenance with the NWDI)
How to work with back transports
After a software version has been deployed in the production system, you are confronted with the problem that you need to patch the production state, while at the same time you are developing new functionality in the development location. To avoid double maintenance of these corrections, they are transported automatically to the development location if a repair connection is configured between the tracks.
The following procedure outlines the back transport process for the developers:
- Release your transport. It shows up in the import queue of the previous track immediately.
- Import the transport.
- Check in the conflict view after the import into DEV, resolve the conflicts and activate the change.
- Release your transport if you had to resolve a conflict. This resolves the conflict in the follow-on workspaces automatically.
Track Landscape for the Development of Scenarios with Deployment on Multiple Production Systems
To realize more complex development scenarios, it is possible to combine multiple tracks in a track chain. In this way, it is possible to set up a succession of development phases or maintenance steps before the development is deployed in the productive systems.
(For information about the setup of production tracks, see (http://help.sap.com -> … -> Automated Deployment into Multiple Production Systems)