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.
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.
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.
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.
Important
Carefully select the packages and modules in the versioned custom software source. When promoted to a lifecycle stage, the service installs all content in the 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.