デプロイ・プロセスの理解

24.2 デプロイ・プロセスの理解

アプリケーションをデプロイする際の様々な方法やベスト・プラクティスについて説明します。

推奨環境について
開発環境、テスト環境および本番環境のベスト・プラクティスについて説明します。
考慮するデプロイメント・シナリオ
APEXアプリケーションの一般的なデプロイメント・シナリオを確認します。

24.2.1 推奨環境について

開発環境、テスト環境および本番環境のベスト・プラクティスについて説明します。

開発者は、アプリケーションを開発する際に、標準的なシステム開発のライフ・サイクル事例に従い、開発、テストおよび本番の3つの環境を用意することをお薦めします。開発環境では、開発者はアプリケーションおよび関連データベース・オブジェクトの変更のみを行うことがベスト・プラクティスとなります。このポリシーを一層強化するために、テスト環境と本番環境の両方にランタイム環境を使用することをお薦めします。この方法により、開発者がこれらの環境でアプリケーション・ビルダーおよびSQLワークショップにアクセスすることが禁止されます。一般的に、テスト環境と本番環境を更新する権限は、管理者(DBA)のみが持つようにします。DBAは提供された適切なAPIを使用し、SQL*PlusやOracle SQL DeveloperコマンドラインなどのSQLインタフェースからアプリケーションをインポートする必要があります。

24.2.2 考慮するデプロイメント・シナリオ

APEXアプリケーションの一般的なデプロイメント・シナリオを確認します。

アプリケーションを開発する場合は、特定のワークスペース内でアプリケーションを作成します。各ワークスペースには、一意のIDおよび名前が含まれます。通常は、開発インスタンスでアプリケーションを作成し、本番インスタンスにアプリケーションをデプロイします。

考慮するデプロイ・オプションには、次のものがあります。

同一ワークスペースおよび同一スキーマの使用: アプリケーションをエクスポートしてからインポートし、別のアプリケーションIDを使用してインストールします。この方法は、基礎になるオブジェクトに対する変更は少ないが、アプリケーションの機能に対して頻繁に変更がある場合に有効です。
別のワークスペースおよび同じスキーマの使用: アプリケーションをエクスポートしてから別のワークスペースにインポートします。この方法は、開発者によって本番アプリケーションが変更されないようにするために有効です。
別のワークスペースおよび別のスキーマの使用: アプリケーションをエクスポートしてから別のワークスペースにインポートし、異なるスキーマを使用するためにアプリケーションをインストールします。この新しいスキーマには、アプリケーションに必要なデータベース・オブジェクトが含まれている必要があります。
すべてのバリエーションによる別のデータベースの使用: アプリケーションをエクスポートしてから別のAPEXインスタンスにインポートし、異なるワークスペース、スキーマおよびデータベースを使用してインストールします。

ワークスペースをコピーするかどうか

既存のワークスペースをコピーするかどうかを判断する際に、プリファレンスが問題になります。本番バージョンでは関係するすべてのオブジェクトへのアクセスが必要であることを覚えておいてください。たとえば、次のような場合にワークスペースをコピーする必要があります。

開発環境と他の環境の間で同じアプリケーション識別子を保持する場合。
アプリケーションがAPEX認証に依存する場合。ワークスペースをコピーすると、自動的にすべての必要なユーザー・データが移行されます。

データベースをコピーするかどうか

データベースをコピーするかどうかを判断する際、アプリケーションが実行されるスキーマは、開発インスタンスと同じオブジェクトにアクセスする必要があることを覚えておいてください。スキーマの実際の名前は重要ではありません。スキーマ名は、インポート・プロセスで変更できます。

アプリケーションIDについて

開発バージョンと本番バージョンのアプリケーションで、アプリケーションIDを一致させる必要はありません。実際、ベスト・プラクティスとして、アプリケーションにアプリケーションIDをハード・コードしないでください。かわりにアプリケーションの別名(アプリケーションの編集ページで定義される)を使用するか、組込み置換文字列(APP_ID、APP_ALIASなど)を使用します。置換文字列は、アプリケーションの機能に影響なくアプリケーションIDを変更できるため、置換文字列の使用をお薦めします。