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. OS Management Hub provides lifecycle environments for managing Oracle Linux deployments using this approach.

To use lifecycle environments, you:

• Create a lifecycle environment with the stages that you need (for example, development, test, and production). A minimum of two stages is required. The maximum is five stages.
• Assign instances to a stage in a lifecycle environment.
• Create a versioned custom software source to specify packages and modules you want to deploy on instances.
• Promote the versioned source through the pipeline from one lifecycle stage to the next (for example, from development to test and finally to production). Promotion installs all content in the versioned source on instances in the stage. See What happens when you promote content to a stage?

See Video: Managing OS Updates with Lifecycles for a tutorial on lifecycle environments.

What is a versioned custom software source?

A versioned custom software source is a custom software source specifically used in lifecycle environments. See Creating a Versioned Custom Software Source.

A versioned custom software source has several distinct attributes:

• Version designator: During creation, you assign a version to the software source.
• Specific package content: During creation, you use filters or a package list to limit the content. A versioned custom software source should only include the packages and modules you want to install on target instances. When creating a versioned custom software source with filters, the latest-only option is required.
• Immutable: Once created, you can't change the packages and modules in the software source, or its version.

Carefully select the packages and modules in a versioned custom software source. When promoted to a lifecycle stage, the service installs all content in a versioned source to the target instances.

What happens when you promote content to a stage?

When promotion occurs, the service:

• Detaches previously attached software sources from the instance.
• Attaches the versioned custom software source associated with the lifecycle stage to the instance.
• Installs all the packages and modules in the attached versioned custom software source to the instance.

What happens when you attach an instance to a stage?

An instance is a member of one and only one stage. You can 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

When attaching an instance to a lifecycle stage, the service:

• Detaches previously attached software sources from the instance.
• Attaches the versioned custom software source associated with the lifecycle stage to the instance.
• Installs all the packages and modules in the attached versioned custom software source to the instance.

If the lifecycle stage doesn't yet have a versioned custom software source promoted to it, no changes are made to the instance. However, you can no longer manage the instance as standalone (such as Updating a Standalone Instance). At the next promotion of a versioned custom software source, the service will refresh the packages and modules on the instance.

What happens when you detach an instance from a stage?

When detaching an instance from a lifecycle stage, the service:

• Removes the instance from the lifecycle stage.
• Detaches the versioned custom software source.

After detaching the instance, it no longer has any software sources associated with it and won't receive updates. You can manage it as a standalone instance or assign the instance to a group or another lifecycle.

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 stages are used to manage monthly patch releases.

New monthly release in Development

Suppose your fleet is already running the patch release, Monthly-2024.05. The operations staff starts preparing the next monthly release. They create a new versioned custom software source (Monthly-2024.06) and promote it. Instances assigned to the Development stage are refreshed with the Monthly-2024.06 content.

Release promoted to Test

After development completes on Monthly-2024.06, the operations team promotes the content to the Test stage where the Quality Assurance (QA) team starts their testing. Instances assigned to the Test stage are refreshed with the Monthly-2024.06 content.

Next monthly release in Development

As the QA team continues their testing and validation of Monthly-2024.06, the operations team begins work assembling the next monthly release. Operations creates and promotes a new versioned custom software source (Monthly-2024.07) to the Development stage.