5.2 アプリケーションのライフサイクル
アプリケーションの配布はアプリケーションがターゲット・システムに正しくインストールされたら終了するのではありません。ここからが始まりです。
ユーザーのアプリケーションは、小さなまたは大きなアップデートを受け取り、LANSAの新バージョンがインストールされ、または既存のアプリケーションと一緒にアプリケーションの新バージョンのインストールが必要になることがあります。これらやその他のバージョンは、アプリケーションの有効期間を通じてユーザーのソフトウェアをどのように管理し発展させるかを決定します。
次のシナリオでは、ユーザーのソフトウェア開発の管理方法の１つを説明しています。
このシナリオでは、異なるバージョンでのアプリケーションの開発をサポートするために3つの開発環境が必要です。
アプリケーションの開発は、BL2区画のバージョン 13 LANSAシステム V13PGMLIB上のバージョン 1.0.0で開始します。バージョン 1.0.0がリリースされ配布された後、パッチ1.0.0.1 と 1.0.0.2が、アプリケーションの小さな変更として異なる日付でリリースされます。これらのパッチは既存のソフトウェア製品に適用されます。ユーザーは、両方のパッチをインストールしなければならない場合もありますが、各パッチがお互いに独立してインストールできる場合もあります。
より重要なアプリケーションの機能強化が計画され完了すると、強化されたアプリケーションはバージョン 1.0.1としてリリースされます。この変更に続くバージョン 1.0.1のマイナーチェンジは、1.0.1.1から始まるパッチとしてリリースされます。
この時点で、アプリケーションに一連の大きな機能強化が計画されます。これは、バージョン 2.0.0としてリリースされます。すべてのアプリケーションのユーザーがすぐにバージョン 2.0.0にアップグレードする必要がある/都合がよい/金銭的余裕があるわけではないと予想されるため、このバージョンはスタンドアロンアプリケーションとしてリリースされ、バージョン 1.0.1へのサポートと修正の提供は継続されます。
そのために、すべてのアプリケーションのオブジェクトが、同じLANSAシステムのBLD区画からBLD２区画にエクスポートされます。製品のバージョン 1.0.1の開発とリリースは引き続きBLD区画内で継続されますが、BLD２区画内のアプリケーションの分岐はバージョン 1.0.1に影響を与えずに修正できます。
この、異なる区画で共有されるLANSAシステムの意味は次のとおりです。
- 2つの区画がアプリケーション定義を共有します。バージョンとパッチを生成する際、正しい区画にログインすると同時に注意が必要です。
- どちらのアプリケーションのバージョンも同じLANSAのバージョンがもとになっています。これにはEPCが含まれます。
そのために問題が起こります。バージョン 1.0.1とバージョン 2.0.0のサポートを継続したいが、新しいLANSAがリリースされ、そのソフトウェアの機能を利用してユーザーのアプリケーションを強化したい場合はどうすればよいでしょうか。
この場合、第2LANSAシステム ABCPGMLIBをリリース・レベル V13SP1でインストールしてください。すべてのアプリケーションのオブジェクトを、ユーザーのアプリケーションの最新のバージョン(この場合はBL2区画)からエクスポートし、LANSAシステム ABCPGMLIBの新しいABC区画にインポートします。新しいLANSAシステムのセットアップを終了するには、X_APPSのアプリケーション定義と、オプションとして関連付けられたバージョンとパッチ定義(履歴の参照のみ）も新しい位置にコピーしてください。「アプリケーションのバックアップまたは修復」を使って共通の位置にコピーできます。バージョン 2.0.0をバージョン 3.0.0にアップグレードしたい場合、最初のアプリケーションのGUIDが必要なため、アプリケーションのコピーは重要です。