Red Hat Satellite 6 Administration

Use lifecycle environments to manage software package and errata releases. Create lifecycle environments to match each stage of your specific application lifecycle. The sequence of application stages as lifecycle environments forms an environment path. You can create as many environment paths as needed to represent each unique application lifecycle in your organization.

The first environment in every environment path is the Library environment that receives synced content from available sources. The Library environment is continuously syncing with source repositories, which are configured by the sync plans that you assigned to each repository.

A host that is assigned to an environment path's Library environment has immediate access to the latest synced packages and errata, which might be useful if that host's purpose is to validate incoming content. However, most system purposes, such as a developer workstation or testing system, require explicit software version control. Additional lifecycle environments in an environment path use promoted content views to define the available content for each environment. Content views are discussed later in this course.

Create a lifecycle environment path by using these steps:

Figure 2.1: Create an environment path

After you create an environment path, extend it by adding more lifecycle environments that match the relevant application lifecycle. To extend an environment path with another environment, follow these steps:

Figure 2.2: Extend an environment path

To remove a lifecycle environment, navigate to the Lifecycle Environment Paths page and click the name of the lifecycle environment to remove. Click Remove Environment.

Figure 2.3: Removing a lifecycle environment

When working with the CLI, include the --organization option to perform the task in the correct organization context.

Every lifecycle environment follows either the Library environment or another environment. Adding a lifecycle environment to follow the Library environment initiates a new lifecycle environment path. Adding a lifecycle environment after another environment in a path extends the existing lifecycle environment path. Use the hammer command --prior option to specify the existing environment that the new environment follows. Use unique and easily identifiable values for each environment name and description, because you would regularly rely on those values to distinguish different lifecycle paths and environments.

[root@satellite]# hammer lifecycle-environment create \
--organization myorg --name Dev \
--description "Development Environment" \
--prior Library
Environment created.

The following example lists the lifecycle environments in the myorg organization, including the ID for each environment.

[root@satellite]# hammer lifecycle-environment list --organization myorg
---|---------|--------
ID | NAME    | PRIOR
---|---------|--------
15 | Build   | Library
16 | Deploy  | Build
12 | Test    | Dev
11 | Dev     | Library
10 | Library |
---|---------|--------

The following example lists the same organization's environment paths in a simpler form.

[root@satellite]# hammer --output base lifecycle-environment paths \
--organization myorg
Lifecycle Path: Library >> Build >> Deploy

Lifecycle Path: Library >> Dev >> Test

The following example deletes the Deploy lifecycle environment from the myorg organization.

[root@satellite]# hammer lifecycle-environment delete \
--name Deploy --organization myorg
Environment deleted.

In this scenario, all content is published through a single lifecycle environment path of multiple environments. This approach manages a development workflow that uses different personnel and hosts for the development and testing stages of the application lifecycle. Content is published to the Development stage to become available to developer workstations. When the developed software is ready for a version release, the developed content is published to the Testing stage. While the software is being tested on Testing hosts, the Development stage can be updated to work on the next software version. When testing and fixes are completed, software is published to the Production environment.

Figure 2.5: An environment path that contains multiple environments

Commonly, organizations have more complex requirements than the previous examples. Red Hat recommends using multiple lifecycle environment paths to manage content hosts with multiple lifecycle requirements. Each application lifecycle manages an independent software publishing cycle.

In this scenario, the organization's developers create web content that requires both quality assurance (QA) testing and functional user acceptance testing (UAT) before release. The base operating system for the organization's web servers does not require the same testing, and is published by using an environment path that includes only a Test stage for system integration testing before publishing to the Production environment.

Figure 2.6: Content-specific lifecycle environment paths