Oracleソフトウェア・ライブラリには、様々なバージョンのソフトウェア・バイナリが格納されます。このライブラリは、自社のハードウェア・サーバーにプロビジョニングされるソフトウェア・コンポーネントのリポジトリとして機能します。
プロビジョニング・アプリケーションは、ユーザーがそのライブラリ・エントリを編集するたびにライブラリ・エントリのバージョンを上げます。
デプロイメント・ライブラリ内のライブラリ・エントリに対する操作で、デプロイされるソフトウェアに変更が発生しない場合、そのライブラリ・エントリのバージョンは更新されません。たとえば、ライブラリ・エントリのプロパティを変更せずに、その成熟度レベルを初期の「未テスト」レベルから「ベータ」レベルに上げた場合、バージョンは同じままです。これは、レベルを上げる操作は、ターゲット・マシンにデプロイされるソフトウェアに影響を与えないためです（ライブラリ・エントリがテスト済またはテスト中であり、本番用にまだ認証されていないというマークを付けるのみであるため）。
同様に、デプロイメント・ライブラリ内で表されるライブラリ・エントリ名またはその説明を変更した場合も、バージョンは変わりません。これもやはり、名前の変更がデプロイされるソフトウェアに影響を与えないためです。ただし、ライブラリ・エントリの構成プロパティを変更した場合または新規バイナリ・データを設定した場合、これらの変更はターゲット・マシンにデプロイされるソフトウェアに影響を与えるため、プロビジョニング・アプリケーションはライブラリ・エントリのバージョンを上げます。
ライブラリ・エントリの作成前に、ライブラリ・エントリの編成が容易になるようにフォルダを作成できます。フォルダには、他のフォルダおよびライブラリ・エントリを格納できます。
たとえば、ソフトウェア・コンポーネントを2つの異なるタイプのプラットフォーム（X86およびPower PCのLinux）にプロビジョニングする場合、ソフトウェア・コンポーネントはプラットフォーム固有であるため、別々に保存する場合があります。この場合、X86という最上位フォルダとPower PCという別のフォルダを作成できます。これで、プラットフォーム・タイプに基づいて、これらのフォルダの下にソフトウェア・コンポーネントを編成できます。
または、最上位にLinux OSフォルダを作成し、その下にX86オペレーティング・システム用とPower PCオペレーティング・システム用のサブフォルダを作成することもできます。
プロビジョニング・アプリケーションは、ライブラリ・エントリのライフサイクルの保守に役立つ次の2つの機能を提供します。
プロビジョニング・アプリケーションを使用すると、ライブラリ・エントリのライフサイクルを容易に管理できます。作成ウィザードでは、ライブラリ・エントリ（コンポーネント）を、完全に構成する前に保存できます。たとえば、ソフトウェア・コンポーネントの作成を開始した後で、ソフトウェア・コンポーネントに対していくつかのステージ・ディレクティブが必要であることに気付いた場合などに利用できます。この場合は、その時点でソフトウェア・コンポーネントを保存し、「ディレクティブ」タブに切り替えて、作成したステージング・スクリプトでステージ・ディレクティブを作成した後、保存したソフトウェア・コンポーネントに戻り、それを編集して新規ステージ・ディレクティブを割り当てることができます。
すべての必須プロパティを割り当てる前にソフトウェア・コンポーネントを保存すると、デプロイメント・ライブラリ内のライブラリ・エントリのステータスは「不完全」になります。不完全なライブラリ・エントリはソフトウェア・コンポーネント、イメージまたはスイートに組み込むことはできません。未設定の必須プロパティを設定して、ライブラリ・エントリを完全にする必要があります。プロビジョニング・アプリケーションは、割り当てられていないすべての必須プロパティをページ上部にリストします。すべての必須プロパティに適切な値を指定すると、プロビジョニング・アプリケーションはライブラリ・エントリのステータスを「準備完了」に設定します。
必要なすべての構成プロパティへの値の設定は、ライブラリ・エントリを準備完了の状態にするために必須ではありません。最初にライブラリに入れるときにプロパティの値を明示的に指定しないままにすることが適切な場合があります。これらのプロパティ値は、ソフトウェア・コンポーネントまたはディレクティブを組み込む（参照する）イメージ内で後で設定できます。
たとえば、ソフトウェア・コンポーネントが実行時に特定のポートでリスニングする場合、イメージへの割当て時またはハードウェアへのデプロイ時にポート番号が構成可能になるようにソフトウェア・コンポーネントを設計すると、そのソフトウェア・コンポーネントをイメージに組み込むユーザーは、ポート番号の値を指定することも、値を指定しないままにすることもできます。ポート番号がイメージ内で未指定のままである場合は、イメージをハードウェア・サーバーにデプロイする前にオペレータが値を設定する必要があります。また、デフォルトのポート番号を割り当てておくこともできます。デフォルトは、イメージ内で、つまりイメージのデプロイ時の操作で、上書きされない場合に使用されます。
準備完了の状態に設定されているライブラリ・エントリは、ソフトウェア・コンポーネント、イメージまたはスイートに組み込むことができます（そのエントリから参照できます）。このライブラリ・エントリをイメージ（または参照をサポートするその他のライブラリ・エントリ）から参照すると、その参照は、ライブラリ・エントリの特定のバージョンに結び付けられます。ライブラリ・エントリの重要な事項を変更した場合、コンポーネントを参照しているイメージは、以前と同じバージョンのライブラリ・エントリを参照します。この機能によって、コンポーネント開発者によるイメージの破壊が防止されます。イメージが新しいバージョンを参照するようにする場合は、新規コンポーネントを参照するようにイメージを変更できます（この結果、イメージの新規バージョンが作成されます）。
ライブラリ・エントリを更新したときに、旧バージョンを他のユーザーが今後（新規イメージの作成時に）参照しないようにする場合は、そのライブラリ・エントリに「非アクティブ」のマークを付けることができます。ライブラリ・エントリに非アクティブのマークを付けると、バージョンは変更されませんが、ユーザーは非アクティブのコンポーネントが含まれるイメージをプロビジョニングできなくなります。ライブラリ・エントリに非アクティブのマークを付けても、それが組み込まれている（それを参照している）既存のイメージには影響を与えません。
非アクティブのライブラリ・エントリは、再アクティブ化することによって準備完了の状態に戻すことができます。ライブラリ・エントリは、再アクティブ化されると、再度新規イメージ（および参照をサポートするその他のライブラリ・エントリ）に組み込むことができます。
重要: ライブラリ・エントリおよびそれを使用するイメージを更新すると、特定のライブラリ・エントリのバージョンが不要になる場合があります。デプロイメント・ライブラリの領域を解放するために、不要なライブラリ・エントリのバージョンを削除できます。削除できるのは、その特定のライブラリ・エントリのバージョンがハードウェア・サーバーにデプロイされていない場合にかぎります。
これは、ライブラリ・エントリの特定のバージョンは、他のライブラリ・エントリから参照されていない場合のみ削除できることを意味します。さらに、イメージまたはスイートは、ハードウェア・サーバーに現在デプロイされている場合は削除できません。
改訂を数回繰り返すと、イメージの古いバージョンはハードウェア環境にデプロイされなくなります。これらのイメージは削除できます。イメージが削除されると、そのイメージはソフトウェア・コンポーネントおよびディレクティブのセットを参照しなくなります。ソフトウェア・コンポーネントおよびディレクティブの特定のバージョンは、他のライブラリ・エントリから参照されなくなった場合、安全に削除できます。
プロビジョニング・アプリケーションは、各ライブラリ・エントリの成熟度レベルを保守します。成熟度レベルは、「未テスト」、「ベータ」または「製品」のいずれかです。
ライブラリ・エントリが最初に作成されたときまたは更新されたとき、プロビジョニング・アプリケーションは成熟度レベルを「未テスト」に設定します。この成熟度レベルは、次のレベルに上げるまたは下のレベルに下げることによって、必要なときにいつでも変更できます。あるライブラリ・エントリが別のライブラリ・エントリを参照しているときは、参照されている項目によってその成熟度レベルが限定されます。
たとえば、Linux OSコンポーネントを作成し、それをイメージに組み込む場合を考えてみます。最初、両方のエントリの成熟度レベルは「未テスト」です。その後、イメージを（OSコンポーネントとともに）テスト・マシンにデプロイし、いくつかのテストを実行します。その時点で、そのイメージが、さらに厳密なテストを担当するグループによるベータ・テストの準備が完了したと判断します。このとき、Linux OSコンポーネントとイメージのレベルを「ベータ」に上げることができます。テストを担当する組織は、イメージの新規バージョンはベータ・テストの準備が完了したと判断し、イメージを最適なテスト環境（テスト目的で指定されたハードウェア・サーバー）にプロビジョニングできます。
この例を先に進め、ベータ・テスト・チームは、Linux OSコンポーネントで使用されている新規バージョンのRPMが、OS上で実行するように指定されている一部のソフトウェアと互換性がないと判断したとします。テスト・チームは、実行する必要があるRPMのバージョンを識別するバグ・レポートを整理し、バグを初期テスト者に渡します。
参照インストール・マシンではRPMのセットがまだ実行されているので、参照マシン上の古いバージョンのRPMをインストールすることを決定します。この場合は、プロビジョニング・アプリケーションに戻り、デプロイメント・ライブラリ内のLinux OSコンポーネントにナビゲートし、編集します。次に、更新されたRPMのセットを参照インストールから再生成し、今度は、問題となったRPMの古いバージョンが設定されたLinux OSコンポーネントの新規バージョンを作成します。この新規バージョンの成熟度レベルは未テストに設定されます。その後、イメージにナビゲートし、Linux OSコンポーネントの新規バージョンを参照するようにそのイメージを編集します。デプロイして実行を確認した後、新規バージョンを「ベータ」レベルに上げます。
テスト・チームは、イメージの新規バージョンを調べ、既存のテスト・ハードウェア・サーバーに再デプロイします。テスト後、テスト・チームは正常に動作すると判断します。その後、イメージとそのすべての参照ライブラリ・エントリを「製品」レベルに上げます。
この時点で、本番システムにイメージをプロビジョニングするように指示されたオペレータに、新規イメージの設定が任されます。イメージは、製品レベルに設定されるまで、本番用に指定されているハードウェア・サーバーにプロビジョニングすることはできません。オペレータは、スケジュールされている次回のメンテナンス期間（この変更の緊急性に応じた適切な時期）に新規イメージをプロビジョニングできます。
関連トピック
Copyright (C) 1996, 2007, Oracle. All rights reserved.