Understanding Lifecycle Environments

Many Oracle Linux environments implement an application and system software lifecycle approach known as DTAP, which stands for Development, Test, Acceptance, and Production. To support this approach, OS Management Hub provides lifecycle environments for managing Oracle Linux deployments in customer data centers. You move content from one stage to another by promotion, for example, from development to test to production.

When you create a lifecycle environment in OS Management Hub you start with naming the lifecycle environment and defining its stages. Each stage constitutes a phase in the lifecycle environment. For example, you might define a lifecycle environment with three defined stages: development, test, and production. A minimum of two stages is required. The maximum is five stages.

You then assign instances to a stage in the lifecycle environment by using one of the following methods:

• Registering a new instance with a lifecycle environment profile
• Attaching existing instances to a stage in a lifecycle environment

To manage content in the lifecycle environment, you create a versioned custom software source, which is a type of custom software source that's given a version and is immutable. Then you promote content by associating a versioned custom software source to a lifecycle stage. Only the instances assigned to that stage have access to the content in the versioned custom software source.

Example of Promoting Content through Lifecycle Stages

The following example illustrates a lifecycle environment with three stages (Development, Test, and Production) and describes how lifecycle environments are used to deploy two software releases: a minor patch release (v1.1) and major release (v2.0).

Suppose that after a major release (v1.0), the Engineering team starts to work on a minor release with patches. Engineering creates a new versioned custom software source (v1.1) and promotes the content to the Development stage in the lifecycle environment.

After development is completed on v1.1, the Engineering team promotes the content to the Test stage where the Quality Assurance (QA) team then starts their testing. Instances assigned to the Test stage now have access to the content in v1.1.

As the QA team continues their testing on v1.1, the Engineering team begins work on the next major release, v2.0, and promotes a new versioned custom software source (v2.0) to the Development stage.