Working with Development Tracks 

Purpose

A development track maps the life cycle of one or more software components from development to delivery. Individual development configurations define a specific state of a software component in its lifecycle. The definition of fixed states such as development, consolidation, test and production guarantees the quality of the delivered component version.

Prerequisites

You have configured a development track in the Change Management Service (CMS), and specified which software components you are going to develop in this track.

In the development environment, you have downloaded the development configuration whose software component you want to work on.

Process Flow

For a detailed description of the local development of a software component, see Working with the SAP NetWeaver Java Development Infrastructure.

Development flow within a development track

 

Then execute the following steps:

...

       1.      After you have completed and tested your development work locally, activate your changes for the central test environment. With the activation, the Component Build Service automatically executes a build which is followed by another automatic deployment in a central runtime system. Here, you can test your changes in the central runtime environment, alongside the changes made by other teams

       2.      If the new state of the software component runs successfully in the central runtime system, you release the activity with the contained changes in the Development Configurations perspective of the development environment. In the context menu of the Transport view, choose Release. (See also Transport View.) The CMS packs the released activity in a change request, which can then be imported into the next system.

       3.      The system administrator imports the pending change requests into the subsequent development configuration (consolidation system) and the CMS there triggers another automatic build and an automatic deployment into a central runtime system.

       4.      After the test in the consolidation system, a system administrator can export in an assembly step the source files and deployable archives from the development configuration. This generates a new software component version, for which the deployment for another test in a test system is executed.

       5.      After the tests in a quality assurance (test) system, the administrator must confirm or reject the quality of the software. Only confirmed software component versions are registered in the component repository of the System Landscape Directory.

       6.      In a multi-layer development you deliver the software component version and place it in the import queue of the subsequent development track. Here, you can develop more software components that are based on the delivered software component.

If after the test system, you configure a runtime system for the productive use of the software component version, the administrator must deploy the version there in an import.

Flow of software changes between multiple development tracks

 

Used software component versions that are prerequisites for the development of a software component are included in the transports through tracks.