効率的かつ安全な開発

厳密な環境とソース・コード制御の使用

明確でセキュアな開発プロセスには、次のように個別の環境およびソース・コード制御を慎重かつ厳格に使用することが不可欠です。

多くの顧客は、少なくとも2つ(通常は3つ以上)の個別の環境を使用します。開発、テスト、ステージおよび本番の各環境は一般的です。厳密な制御を使用して環境間で行います。

ソース・コントロール・システムは、アーティファクトの一貫性を保証する必要があります。

表作成のためのMetadata
サンプルおよびソース・データ
ETLコード
PaaSのバージョンとパッチ・レベル

メタデータの展開を制御する「メタデータ・スチュワード」を考慮し、すべての開発者が同じ定義を使用するようにします。また、dev環境以外の環境にアーティファクトをインポートするタイミングを制御する「リリース・マネージャ」、および目的に応じてどの環境を使用するかを常に把握する「リリース・マネージャ」を指定することも検討してください。

専用環境には、いくつかの利点があります。本番環境に加えて、dev、testおよびperformance環境を考慮してください。これらの環境は必要に応じてスケールできます。

Dev環境の場合:

コードに加えたすべての変更(マイナーな変更も含む)が開発されます。
ユニット・テスト(サンプル・データの使用–多くの場合、実績データのサブセットの高速実行)が実行されます。
プロモーションの準備ができたコードは、次のように識別する必要があります。プロセスを実装して、コードをレビューし、テスト環境または本番環境に自動的に昇格させることができます。

QA環境の場合:

Devで行われた変更の統合(プロモーションのために検証された変更のみ)。
(同じメタデータ、一貫性のあるオーケストレーションなどを使用して)変更の一貫性と、そのコードが適切に実行されることの検証。
コードの変更は許可されていません。

パフォーマンス・テストに使用される追加の環境が有利です。パフォーマンス環境では:

コードのパフォーマンスのためのベースラインを設定します。
パフォーマンス向上の検証のため、パフォーマンス・チームのみが許可するコード変更を制限します。
ボトルネックを特定し、調査し、必要な変更をレポートして、開発で実装できるようにします。
QAチームが認定したすべてのコードでパフォーマンスを監視し、パフォーマンス・ドリフトや住所の問題を確認してください。

本番環境のパフォーマンスの監視を続けることが重要です。パフォーマンスの低下は、環境の低下を警告する場合があります。特に、Oracleでは、SQL Plan Management (SPM)を使用して実行計画を制御することをお薦めします。本番での実行計画の変更は障害の原因となり、表のロードが原因で実行計画の変更リスクが発生します。

管理タスクの自動化

手動管理タスクには時間がかかり、リスクが追加されます。

ロードを再試行するために(コード・エラー、製品の不具合、コードの変更などにより)環境を手動でリセットすると、SQL文を手動で実行する開発者に依存します。
手動プロセスでエラーが発生しやすいため、エラーが発生し、次の試行をさらに遅延できます。
手動のプロセスに時間がかかる:開発者は、処理内容に注意し、適切な処理が実行されていることを再確認する時間を省く必要があります。
エラーはコストが高いため、エラーを修正する必要があります(消去されたデータを再ロードする可能性あり)。開発作業を遅らせることがあります。
新しい開発者のオンボーディングは、手動プロセスに従うようにトレーニングする必要があるため、低速でリスクが大きくなります。

管理タスクは完全に自動化する必要があるため、開発者は少数のパラメータを設定し、毎回正しいタスクを実行することがすでに検証されたジョブを実行します。

次の作業を自動化することを検討してください。

環境データ、変数およびパラメータをリセットして、ロードを再試行できるようにします。
環境の再構築:必要に応じてPaaSツールおよびパッチ、メタデータ、データ、PaaSコード。これには、ターゲット環境の初期ロードを実行する機能も含まれている必要があります。
Oracle Data Integratorログとシナリオ・レポートをパージします(パフォーマンスが向上する)。パッケージで使用可能なOdiPurgeLogツールは、専用シナリオの作成およびパージのスケジュールに使用できます。
正常に実行されたロードに使用されたステージング表をパージします。
正常にロードされたファイルをパージまたは再検出します。
パッチを適用する場合は、サイレント・インストール(開発環境でパッチ適用プロセスを記録し、他の環境で再実行)を使用します。

パッチ適用の管理

パッチの適用は最新のセキュリティおよびバグの修正で更新されたシステムを維持するために重要ですが、よく管理されていないパッチのレジストリで脆弱性が生じ、予想外の停止時間イベントが発生する可能性があります。

Oracleの推奨事項:

組織内の誰が、パッチ適用についてOracleからアラートを受け取り、それに対応するかを検証します。
すべての環境のパッチ適用レベルを文書化します。一部のサービスは、Oracleにより自動的にパッチ適用およびアップグレードされますが、非ネイティブ・サービス、特にオンプレミスのインスタンスには手動でパッチを適用する必要がある場合があります。
パッチ適用ウィンドウを定義します。手動によるパッチ適用では、ユーザーに対して最も混乱の少ない時間ウィンドウを特定します。

ユーザー・アカウントのベスト・プラクティスの追跡

ユーザー・アカウントでのベスト・プラクティスに従い、データ、環境および統合のセキュリティを保証します。

各開発者には、スーパーバイザ権限が付与されている場合でも、それぞれのOracle Data Integratorユーザー・アカウントが必要です。勘定科目を共有しません。ユーザー・アカウントの分離によって通信が向上し、アカウンタビリティが保証されます。

ロックされたオブジェクトには、オブジェクトの編集中のユーザーが表示されます。
最終更新には、オブジェクトの最終変更者とその日時が表示されます。

Oracle Data Integratorがデータベースにアクセスする必要がある場合:

Oracle Data Integrator専用のデータベース・ユーザーを作成します。個々のユーザーのアカウントまたは別のサービスで使用されるアカウントは再使用しないでください。
Oracle Data Integratorユーザーは、ステージング・スキーマの所有者である必要があります(作成、削除、挿入、更新および削除操作の実行に使用されます)。
Oracle Data Integratorユーザーの権限は、他のスキーマに対する実際の使用(選択、挿入、更新および削除)に限定されます。

多くのユーティリティの使用

他のツールがより優れているため、実際に環境で機能することが証明されているツールを他のツールと統合し、使用すべき内容を新しいチーム・メンバーが認識できるように、標準をドキュメント化してください。

次に例を示します。

キーの生成:キーには複数の形式があります。開発者が使用する正しいキー・フォーマットをドキュメント化してください(たとえば、RSAフォーマットの使用が必要な場合があり、OpenSSHフォーマットが禁止されている場合があります)。
ZIPユーティリティ:異なるユーティリティですべてのコンテンツを圧縮することはできません。ファイルを圧縮するために使用される圧縮アルゴリズムを制御できることを確認してください。Oracleでは7 Zipの使用を推奨しています。