Code Pipeline Codelines and Sandboxes

This section describes concepts such as Code Pipeline Codelines and Sandboxes.

Code Pipeline Codelines

Code Pipeline Codelines extend the Code Pipeline life cycle model to provide a more flexible way to manage concurrent development.  

A basic understanding of the traditional Code Pipeline life cycle model is required to know how Codelines can be used to extend the model.

The Code Pipeline life cycle model is based on a promotional level concept using a hierarchical structure. The life cycle structure is composed of levels. A single level at the top of structure is considered the production codebase and is designated as a PROD level (a level name is modifiable).

To support changes to the production codebase and manage those changes using development life cycle processes, one or more paths of levels can be defined that allow new versions to be promoted through the life cycle structure to the production level. There are 3 types of levels that make up a life cycle structure:


    • TEST level – where new versions of components can be checked out and modified. A life cycle path begins with a TEST level.
    • HOLD level – a controlled level where the contents of a version cannot be modified. These are the intermediate levels in the life cycle path between a TEST level and the PROD level.
    • PROD level – the current production codebase. Only one such level can exist in a life cycle structure.

A life cycle path consists of a TEST level, at least one HOLD level, and the PROD level. Multiple paths can be defined to support concurrent development and a path can contain multiple HOLD levels.

A single life cycle is defined for each Code Pipeline Stream. The Stream concept is provided so that different life cycles can be defined where necessary to support different parts of an organization or different development life cycle practices.

While the Code Pipeline life cycle provides a very flexible structure, it must be pre-defined by the Code Pipeline administrator, and all the required datasets allocated.

Codelines extend the Code Pipeline life cycle model by providing a more dynamic way to define concurrent paths of development without the need to change the existing level structure.

When additional concurrent or isolated development is required, instead of having to define more paths in the level structure, Codelines can be defined and used within the existing level structure.

With the introduction of Codelines, the existing set of life cycle level datasets are considered the standard Codeline. Additional new Codelines can be defined, which have their own separate datasets at each life cycle level where the Codeline may exist. Codelines can only exist at the HOLD or the TEST levels. When a new Codeline is created, a Join at Level must be specified, which is the level at which the Codeline ends. The Codeline can only exist at levels below the Join at level. When versions in the Codeline are promoted to the Join at level, they revert to the regular life cycle datasets as part of the standard Codeline. 

Without using Codelines, a version of a component can be referenced and identified by the life cycle level where that component exists. Using Codelines allows for multiple active versions at a level which is differentiated from the standard Codeline by using a combination of level and Codeline for versioning.

Code Pipeline Codelines provide improved support for a range of development life cycle approaches.

Sandboxes

One common approach to using Codelines is the Sandbox, where an isolated set of versions can be utilized for development. For example, a generate will not include any components that reside in another Codeline. To support this practice, a new option is provided during assignment creation that creates a Codeline with a name based on the Assignment ID. Tasks added and checked out to this assignment are part of that Codeline using their own set of datasets. The datasets are created when required and are deleted when the Assignment is closed. 

You can create a Sandbox Codeline assignment in the following ways:

  • From a Git project, update the .yaml file manually with sandbox: Y (there will be a UI field in the future to use in place of manually updating the .yaml file). See Using-Code-Pipeline-for-Eclipse-with-GIT for more information about using Git.
  • From the Add New Assignment dialog box when creating a new assignment; See Create-a-New-Assignment for information about creating a new assignment, which includes creating a Sandbox Codeline for an assignment.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*