Chapter 6. Creating an Application Life Cycle

In Section 1.2, “Defining the Application Life Cycle”, we defined what an application life cycle is and why it is important to Red Hat Satellite 6. In this chapter, we take a closer look at planning the application life cycle and implementing it in Red Hat Satellite 6.

6.1. Revisiting the Application Life Cycle

As we discussed, the application life cycle defines how systems appear at a certain stage. However, the actual application life cycle depends on your organization and how it structures a particular production chain.

For example, an email server might only require a simple application life cycle where you have a production-level server for real world use and a test server for trying out the latest mail server packages. When the test server passes the initial phase, we can set the production-level server to use the new packages.

Another example might be an development life cycle for a software product. You might aim to develop a new piece of software in a development environment, have it tested in a quality assurance environment, pre-release it as a beta, then release it as a production-level application.

Each application life cycle uses a set of stages called environments. Each environment act as a particular state for our systems. Each environment also follows on from a previous environment, creating a chain of environments that becomes our application life cycle. Each application life cycle starts with an initial Library, which acts as a central source in our Definitive Media Library (DML). The Library environment contains all of the content we previously synchronized in our previous chapters. From this point, we create additional environments that link starting from the Library environment.

6.2. Creating a New Application Life Cycle

For our scenario, we aim to create simple application life cycle for developing and releasing ACME’s Exampleware. We use the Library environment as our initial environment, then chain an additional three environments in this order: Development, Testing, and Production.

For Web UI Users

Navigate to Content > Lifecycle Environments. This screen displays the current environments in your application life cycle. At the moment, only the Library environment exists.

Click New Environment Path to start a new application life cycle. A form appears for adding a new environment to Library. Enter Development for the Name and the Label automatically completes. Enter Environment for ACME’s Development Team for the Description. Click Save.

We return to the environments listing. A new table appears with our Development environment. This new table represents our new application life cycle. Now we add the rest of the environments to the application life cycle.

Click Add New Environment just above the new table. This time, enter Testing for Name and Environment for ACME’s Quality Engineering Team for the Description. Click Save.

Finally, click Add New Environment again. Enter Production for Name and Environment for ACME’s Product Releases for the Description. Click Save.

The final application life cycle appears as a table with our three environments: Development, Testing, and Production.

For CLI Users

Run the hammer lifecycle-environment create for each environment. Use the --prior option to specify the previous environment. For example:

# hammer lifecycle-environment create \
--name "Development" \
--description "Environment for ACME's Development Team" \
--prior "Library" \
--organization "ACME"
# hammer lifecycle-environment create \
--name "Testing" \
--description "Environment for ACME's Quality Engineering Team" \
--prior "Development" \
--organization "ACME"
# hammer lifecycle-environment create \
--name "Production" \
--description "Environment for ACME's Product Releases" \
--prior "Testing" \
--organization "ACME"

View your chain with the hammer lifecycle-environment paths command:

# hammer lifecycle-environment paths --organization "ACME"
-----------------------------------------------
LIFECYCLE PATH
-----------------------------------------------
Library >> Development >> Testing >> Production
-----------------------------------------------

6.3. Adding Life Cycle Environments to Capsule Servers

The following is an optional step for environments that use Capsule Servers to provision content.

If your Capsule Server has content functionality enabled, you must add an environment. Adding an environment enables Capsule Server to synchronize content from Satellite Server and provide content to host systems.

Capsule Server is configurable using Hammer CLI on Satellite Server, or through the web UI.

For Web UI Users

Under Infrastructure > Capsules, select the capsule.

Click Edit.

Select Env in the Life Cycle Environments tab.

To synchronize capsule’s content, click the Synchronize button in the Overview tab.

Select one of two options:

  • Optimized Sync
  • Complete Sync

For CLI Users

Display a list of all Capsule Servers and note the ID:

# hammer capsule list

Using the ID, verify the details of your Capsule Server:

# hammer capsule info --id capsule_id_number

Verify the life cycle environments available and note the environment ID:

# hammer capsule content available-lifecycle-environments \
--id capsule_id_number

Available life cycle environments are available for Capsule Server, but not currently attached.

Add the life cycle environment to your Capsule Server:

# hammer capsule content add-lifecycle-environment \
--id capsule_id_number --environment-id environment_id_number

Repeat for each life cycle environment you want to add to Capsule Server.

To synchronize all content from your Satellite Server environment to Capsule Server, enter the following command:

# hammer capsule content synchronize --id capsule_id_number

To synchronize a specific life cycle environment from your Satellite Server to Capsule Server, enter the following command:

# hammer capsule content synchronize --id external_capsule_id_number \
--environment-id environment_id_number

For more information on working with Life Cycle Environments, see Life Cycle Environments in the Architecture Guide.

6.4. Promoting Content across the Application Life Cycle

Content moves from one environment to the next in an application life cycle chain. This is a process called promotion. Promotion is an important concept to understand because it is the basis for managing content across an application life cycle.

For our scenario, let’s say that ACME’s Exampleware is in full development and production. ACME packages their Exampleware content into a RPM file, which becomes part of a separate product. In this situation, ACME might have version 1.0 of Exampleware released, which means exampleware-1.0-0.noarch.rpm is in the Production environment.

ACME wants to release a patch for Exampleware, so they start development on version 1.1 of Exampleware. In this instance, the environments in the application life cycle would contain the following version of Exampleware:

DevelopmentTestingProduction

exampleware-1.1-0.noarch.rpm

exampleware-1.0-0.noarch.rpm

exampleware-1.0-0.noarch.rpm

After completing development on the patch, ACME promotes the RPM to the Testing environment so ACME’s Quality Engineering team can review the patch. The application life cycle then contains the following package versions in each environment:

DevelopmentTestingProduction

exampleware-1.1-0.noarch.rpm

exampleware-1.1-0.noarch.rpm

exampleware-1.0-0.noarch.rpm

While the Quality Engineering team reviews the patch, the Development team starts work on Exampleware 2.0. This results in the following application life cycle:

DevelopmentTestingProduction

exampleware-2.0-0.noarch.rpm

exampleware-1.1-0.noarch.rpm

exampleware-1.0-0.noarch.rpm

The Quality Engineering team completes their review of the patch. Now Exampleware 1.1 is ready for release. ACME promotes 1.1 to the Production environment:

DevelopmentTestingProduction

exampleware-2.0-0.noarch.rpm

exampleware-1.1-0.noarch.rpm

exampleware-1.1-0.noarch.rpm

The Development team completes their work on Exampleware 2.0 and promotes it to the Testing environment:

DevelopmentTestingProduction

exampleware-2.0-0.noarch.rpm

exampleware-2.0-0.noarch.rpm

exampleware-1.1-0.noarch.rpm

Finally, the Quality Engineering team reviews the package. After a successful review, we promote the package to the Production environment:

DevelopmentTestingProduction

exampleware-2.0-0.noarch.rpm

exampleware-2.0-0.noarch.rpm

exampleware-2.0-0.noarch.rpm

This example demonstrates the mapping of ACME’s development process into a Red Hat Satellite 6 application life cycle. Each environment contains a set of systems registered to Red Hat Satellite 6. These systems only have access to repositories relevant to their environment. When we promote packages from one environment to the next, the target environment’s repositories receive new package versions. As a result, each system in the target environment can update to the new package versions.

Another concept we explore in the next chapter is Content Views. A Content View is essentially a collection of content gathered and filtered from the Library and published in its own repository. The Red Hat and custom repositories we synchronized previously act as source content, while the Content Views customize exactly how the end repositories appear. Content Views contain packages and Satellite Server promotes Content Views across environments in the application life cycle. An environment might use one Content View (Version 1.0) but then might receive a new version of the Content View (Version 1.1). The repositories from Version 1.0 are replaced with the repositories for Version 1.1, which might include a new version of the Exampleware RPMs.

6.5. Adding Life Cycle Environments to a Red Hat Satellite Capsule Server

If a newly created Red Hat Satellite Capsule Server has content functionality enabled, the Capsule Server needs an environment added to enable it to synchronize content from Satellite Server and provide content to host systems.

Important

Satellite Capsule Server is configured through Satellite Server’s command line interface (CLI). Enter all hammer commands on Satellite Server.

To Add Environments to Satellite Capsule Server:

  1. Log in to Satellite Server CLI as root.
  2. Select the Red Hat Satellite Capsule Server that you want from the list and take note of its id:

    # hammer capsule list

    To verify Satellite Capsule Server’s details, enter the following command:

    # hammer capsule info \
    --id capsule_id_number
  3. Verify the list of life cycle environments available for the Red Hat Capsule Server and note down the environment id:

    # hammer capsule content available-lifecycle-environments \
    --id capsule_id_number

    Where:

    available-lifecycle-environments are life cycle environments that are available to Satellite Capsule but are currently not attached to Satellite Capsule.

  4. Add the life cycle environment to Satellite Capsule Server:

    # hammer capsule content add-lifecycle-environment \
    --id capsule_id_number \
    --environment-id environment_id_number

    Where:

    • capsule_id_number stands for Satellite Capsule Server’s identification number.
    • environment_id_number stands for the life cycle environment’s identification number.

    Repeat this step for every life cycle environment to be added to the Capsule Server.

  5. Synchronize the content from Satellite Server’s environment to Satellite Capsule Server:

    # hammer capsule content synchronize \
    --id capsule_id_number

    When an external Satellite Capsule Server has various life cycle environments, and only one life cycle environment needs to be synchronized, it is possible to target a specific environment by specifying the environment identification number:

    # hammer capsule content synchronize \
    --id external_capsule_id_number \
    --environment-id environment_id_number

6.6. Promoting Content Views

After you have created a Content View and an environment path consisting of two or more life cycle environments, you can promote the Content View from one environment to the next as required. This means that the most recent version of the Content View that exists in a specified environment is promoted, or copied, to the next environment in the life cycle environment path.

You can promote a Content View to any environment where that version does not exist. The system automatically suggests the next environment in the life cycle environment path, but you can override this and promote to a different environment if required.

To Promote a Content View:

  1. On the main menu, click Content > Content Views.
  2. In the Name column, click the name of the Content View that you want to promote.
  3. On the Versions tab, identify the latest version, and click Promote.
  4. Identify the promotion path where you want to promote the Content View, select the appropriate life cycle environment, and click Promote Version.
  5. After the promotion has completed, the Versions tab updates to display the new status of your Content Views.

6.7. Removing Life Cycle Environments from Satellite Server

This procedure describes how to remove a life cycle environment from Red Hat Satellite.

To Remove a Life Cycle Environment:

  1. On the main menu, click Content > Life Cycle Environments.
  2. Click the name of the life cycle environment that you want to remove, and then click Remove Environment.
  3. In the confirmation dialog box, click Remove to remove the environment.
Note

You can only delete the latest environment in an environment path. For example, if three environments exist in the order Library, Dev, and Prod, you need to delete Prod before you can delete Dev. You cannot delete the Library environment.

6.8. Removing Life Cycle Environments from Capsule Server

There are multiple reasons to remove life cycle environments from Capsule Server. For example:

  • When life cycle environments are no longer relevant to the host systems
  • When life cycle environments have been incorrectly added to Capsule Server

To remove a life cycle environment from Capsule Server:

  1. Log in to Satellite Server CLI as the root user.
  2. Select the Capsule Server that you want from the list and take note of its id:

    # hammer capsule list

    To verify the Capsule Server’s details, enter the following command:

    # hammer capsule info \
    --id capsule_id_number
  3. Verify the list of life cycle environments currently attached to the Capsule Server and take note of the environment id:

    # hammer capsule content lifecycle-environments \
    --id capsule_id_number
  4. Remove the life cycle environment from Capsule Server:

    # hammer capsule content remove-lifecycle-environment \
    --id capsule_id_number \
    --environment-id environment_id_number

    Where:

    • capsule_id_number is the Capsule Server’s identification number.
    • environment_id_number is the life cycle environment’s identification number.

      Repeat this step for every life cycle environment to be removed from the Capsule Server.

  5. Synchronize the content from Satellite Server’s environment to Capsule Server:

    # hammer capsule content synchronize \
    --id capsule_id_number

6.9. Chapter Summary

This chapter returned to the concept of the application life cycle and how it applied to Red Hat Satellite 6’s content management. This chapter also explored how Red Hat Satellite 6 promoted content across the environments in the application life cycle.

The next chapter discusses Content Views and how they are used to create custom filtered repositories from our existing DML.