Understanding Lifecycle Environments

A lifecycle environment is a user-defined pipeline to deliver select, versioned content in an ordered manner.

Instances best suited for lifecycle environments are appliance-like and have minimal tolerance for variability in their installed software. You deliver updates to instances as fixed versions of content that you define within a versioned custom software source. The only time the content changes is when a new version is created and promoted to a stage.

You can create a lifecycle environment with a maximum of five stages and assign instances to each stage. Then, create a versioned custom software source with specific package updates to promote through the stages. Promotion installs all content in the versioned source onto the instances in the stage.

Note

Lifecycle environments are different in OS Management Hub than in other products such as Oracle Linux Manager. Once created, you can't update or alter a versioned source. Instances in a lifecycle environment are appliance-like and receive all content from the versioned source. If you need more update flexibility, use groups and custom software sources.

FAQ

How do I use a lifecycle environment?

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. An instance can be in one and only one stage.
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 I 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 I promote content to a stage?

When promoting a versioned source to a lifecycle stage, the service:

Associates the versioned custom software source with the lifecycle stage.
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 I 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:

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 source, the service will attach it to all members of the stage and install all its content.

What happens when I 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 (leaving no software sources attached to the instance).

Important

After detaching the instance, it no longer has any associated software sources 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. The service installs all content in Monthly-2024.06 to instances in the Development stage.
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. The service installs all content in Monthly-2024.06 to instances in the Test stage.
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. The service installs all content in Monthly-2024.07 to instances in the Development stage.

Oracle Cloud Infrastructure Documentation