ここまで見てきたように、アプリケーションライフサイクルはあるステージでシステムがどのように表示されるかを定義します。しかし、実際のライフサイクルは、組織と組織が特定の実稼働チェーンを構成する方法によって異なります。

例えば、E メールサーバーの場合、実際の使用における実稼働レベルのサーバーと、最新のメールサーバーパッケージをテストするテストサーバーという、単純なアプリケーションライフサイクルのみを必要とします。テストサーバーが初期段階をパスすれば、実稼働レベルのサーバーで新パッケージを使用するよう設定できます。

別の例としては、ソフトウェア製品の開発ライフサイクルがあります。開発環境でソフトウェアの新しい部分を開発し、品質保証環境でこれをテストしてベータ版としてプレリリースした後、実稼働レベルのアプリケーションとしてリリースします。

各アプリケーションライフサイクルでは、環境 と呼ばれる段階を使用します。各環境は、システムに対して特定の状態として機能します。各環境は前の環境に続くもので、アプリケーションライフサイクルを構成することになる環境チェーンを作り出します。アプリケーションライフサイクルはそれぞれ、初期の ライブラリー が備わった状態で開始され、これは Definitive Media Library (DML) 内の中央ソースとして機能します。ライブラリー環境には、ここまでの章で同期した全コンテンツが含まれています。ここからは、ライブラリー環境からリンクされる新たな環境を作成します。

本ガイドのシナリオでは、ACME の Exampleware を開発、リリースする単純なアプリケーションライフサイクルを作成します。初期環境にライブラリー環境を使用し、以下の順序で 3 つの環境を続けます: 開発、テスト、および 実稼働。

新規環境パス をクリックして、新規のアプリケーションライフサイクルを起動します。ライブラリーに新規環境を追加するフォームが表示されます。名前 に Development を入力すると ラベル が自動的に完了します。説明 に Environment for ACME's Development Team と入力します。保存 をクリックします。

環境一覧に戻ります。開発環境の新たなテーブルが表示されます。このテーブルは、新規のアプリケーションライフサイクルを示します。これで残りの環境をアプリケーションライフサイクルに追加できます。

新規テーブルの上にある 新規環境の追加 をクリックします。名前 に Testing、説明 に Environment for ACME's Quality Engineering Team と入力して、保存 をクリックします。

再度 新規環境の追加 をクリックします。名前 に Production、説明 に Environment for ACME's Product Releases と入力して、保存 をクリmックします。

これで Development、Testing、および Production という 3 つの環境が揃ったテーブルのアプリケーションライフサイクルが表示されます。

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

hammer lifecycle-environment paths コマンドでチェーンを確認できます。

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

アプリケーションライフサイクルのチェーンでは、コンテンツはある環境から次の環境に移動します。このプロセスは プロモーション と呼ばれます。プロモーションはアプリケーションライフサイクルに渡ってコンテンツを管理する基礎となるもので、これを理解することは重要です。

本ガイドのシナリオでは、ACME の Exampleware の開発が完了しており、実稼働しているとします。ACME は Exampleware コンテンツを RPM ファイルにパッケージ化し、これは別製品の一部となります。この状態では、ACME は Exampleware のバージョン 1.0 をリリースしており、このため exampleware-1.0-0.noarch.rpm が実稼働環境にあることになります。

ACME では Exampleware のパッチをリリースするので、Exampleware バージョン 1.1 の開発を開始します。このインスタンスでは、アプリケーションライフサイクルの環境には以下の Exampleware のバージョンが含まれます。

パッチの開発が完了したら、ACME は RPM をテスト環境にプロモートして、ACME の品質保証エンジニアチームがレビューできるようにします。この時点では、アプリケーションライフサイクルには以下のバージョンが含まれます。

品質保証エンジニアチームがレビューを行う間、開発チームは Exampleware 2.0 の作業に着手します。このため、アプリケーションライフサイクルは以下のようになります。

品質保証エンジニアチームがパッチのレビューを完了したので、Exampleware 1.1 のリリース準備が完了しました。ACME では 1.1 を実稼働環境にプロモートします。

開発チームが Exampleware 2.0 の作業を完了し、これをテスト環境にプロモートします。

最後に品質保証エンジニアチームがこのパッケージのレビューを行います。レビューが完了すると、パッケージは実稼働環境にプロモートされます。

この例では、ACME の開発プロセスを Red Hat Satellite 6 アプリケーションライフサイクルにマッピングするステップを説明しています。これらのシステムがアクセスできるのは、各環境に関連するリポジトリーのみです。ある環境から次の環境にパッケージをプロモートすると、プロモート先のリポジトリーはパッケージの新バージョンを受け取ります。この結果、プロモート先の環境にあるシステムはパッケージを新バージョンに更新することができます。

次章では、コンテンツビュー という概念を説明します。これは、ライブラリーから収集されフィルタリングされたコンテンツのコレクションで、リポジトリーに公開されたものです。Red Hat のリポジトリーとこれまでに同期したカスタムリポジトリーはソースコンテンツとして機能しますが、コンテンツビューは作成したリポジトリーをカスタマイズするものです。コンテンツビューにはパッケージが含まれ、Satellite Server はアプリケーションライフサイクルの各環境にコンテンツビューをプロモートします。ある環境でコンテンツビュー (バージョン 1.0) を使用していても、次に新バージョン (バージョン 1.1) のコンテンツビューを受け取ります。この場合、バージョン 1.0 のリポジトリーは、Exampleware RPM の新バージョンが含まれているバージョン 1.1 のリポジトリーに置き換えられます。

本章ではアプリケーションライフサイクルの概念と Red Hat Satellite 6 のコンテンツ管理について説明しました。また、Red Hat Satellite 6 がアプリケーションライフサイクルの各環境にコンテンツをプロモートする方法についても説明しました。

次章では、コンテンツビューとそれを使用したカスタマイズリポジトリーを既存の DML から作成する方法について説明します。