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 particular state of the software within its life cycle. 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 Server (CMS) and determined, which software components you want to develop in this track.

You have downloaded the development configuration in the development environment, whose software component you want to edit.

Process Flow

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

Development flow within a development track

 

Then execute the following steps:

...

       1.      After the local development and the successful local tests, the changes are activated 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. There you can test the changes in the central runtime environment together with the changes of 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 into a change request and offers this request for import into the subsequent 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 tests in the quality assurance systems (test systems), 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. Based on the delivered software component, you can develop other software components there.

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 several development tracks

 

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