CBS Buildspace
The Component Build Service (CBS) supports the concept of the development configurations by so-called buildspaces. A buildspace is a separate area within a CBS which implements exactly one development configuration. If you create a new track in the Change Management Service (CMS), the buildspaces for the development and the consolidation system are created automatically.
Like the development configuration, a buildspace contains compartments for software component (SC) versions. From the CBS point of view, there are two categories of SC versions:
-
SC versions developed in this configuration
Changes to the respective development components are activated in this buildspace. The buildspace provides storage space for the build results.
-
SC versions used in this configuration.
The relevant development components are built at a different place and imported into the buildspace.
Buildspaces always contain those versions of the involved SCs that are suited for a configuration. In this way, they provide the development teams with a consistent development context. A buildspace provides a semantically consistent environment, comparable to an ABAP development system, which facilitates the development work considerably.
The figure below shows the interaction between CBS buildspace, development configuration and DTR workspaces. In two buildspaces, two different states of the SC WebShop are built: 1.0DEV and 1.0CONS .
In both cases, the software exists as source code, which is why both buildspaces for this SC refer to DTR workspaces. (For DEV and CONS , it is an inactive and an active DTR workspace each).
Interaction Between CBS Buildspace, Development Configuration and DTR Workspaces
In both buildspaces, the SCs BusinessFramework and Technology are used. They are archives that were built in a different buildspace (usually on a different CBS) and imported into these buildspaces. In this example, in the DEV buildspace newer releases of the used SCs were imported, while the CONS buildspace still uses an older version.
You can also use different buildspaces, for example, to build different releases of one SC or to develop completely different SCs.
See also: