Chapter 6. Creating an 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. Once 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.

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.

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.

# 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
-----------------------------------------------

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:

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:

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:

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:

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

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

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 will 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 the 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.

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.