Oracle SQLclプロジェクト開発プロセスの概要 (2024/12/21)

https://danmcghan.hashnode.dev/an-overview-of-the-oracle-sqlcl-projects-development-process

SQLcl Projectsは、Oracle DatabaseおよびAPEXアプリケーションの開発ライフサイクルを標準化および合理化することを目的としたSQLclの新機能です。この投稿では、育成プロセスの概要を説明します。

ここでは、この記事およびSQLclプロジェクト全般について検討する際の用語をいくつか示します。

ソフトオブジェクト- 「作成または置換」構文をサポートするオブジェクトタイプ。例: ビュー、プロシージャ、ファンクション、パッケージ、トリガーなど。
ハードオブジェクト- データまたは状態を含み、「作成または置換」で提供されるよりも注意して移行する必要があるオブジェクト。例: 表、索引、順序、マテリアライズド・ビューなど。

プロセスの概要

コンテキストについては、SQLclプロジェクトを使用したリポジトリの基本的なフォルダ構造を次に示します。

.
├── .dbtools             * SQLcl Projects config
├── .git                 * Git DB (it's required)
├── dist                 * A Liquibase-based installer 
│   ├── install.sql
│   ├── releases
│   └── utils
└── src                  
    └── database         * An export of your DB objects

これらは、開発者がSQLclプロジェクトを使用して機能(またはバグ修正)を完了するために使用する一般的なステップです。

DEV DBでの変更
DEV DB (srcディレクトリ)の変更でリポジトリを同期
Liquibase変更ログ/セットの作成(distディレクトリ)
テストDBでのLiquibase変更ログ/セットのテスト
変更をリポジトリにマージ

各ステップの詳細を説明します...

ステップ1: DEV DBでの変更

このステップでは、作業を完了します。開発チームがアプリケーションに変更を加える方法に正確に影響を与える決定は数多くあります。

個別開発環境と共有開発環境
「ファイル・ファースト」とDBでのオブジェクトの直接操作
Gitブランチ戦略(Gitフロー、GitHubフローなど)
管理者ユーザーとアプリケーション・スキーマ・ユーザーとしてのDEV DBへの接続

これらの意思決定が今後の投稿でアプリ開発にどのように影響するかのニュアンスについて説明します。現時点では、このような決定は作業の遂行方法に影響しますが、SQLcl Projectsはかなり柔軟性があり、通常は関係なく機能します。

ステップ2: DEV DBの変更でリポジトリを同期する(srcディレクトリ)

次に、repoのsrcディレクトリを、機能/バグ修正の一部としてDEV DBに加えられた変更と同期する必要があります。srcは、アプリケーションのデータベース・オブジェクトのエクスポートと考えてください。データベース・オブジェクトは、srcの下にファイルとして編成され、スキーマおよびオブジェクト・タイプ別にグループ化されます。srcの下のファイルは、次の場合に役立ちます。

プル・リクエスト(PR)またはマージ・リクエスト(MR)の相違と、時間の経過に伴う変更の追跡- これは、Gitとそのツール・エコシステムが非常によく行うことです。
ソフト・オブジェクトをデータベースにコンパイルします。ソフト・オブジェクトを変更する必要がある場合は、リポジトリでソフト・オブジェクトを見つけて変更を加え、SQL DeveloperやSQL Developer Extension for VS Codeなどのツールを使用してコンパイルします。

プロジェクト・エクスポート・コマンドでは、srcディレクトリの管理作業の大部分が実行され、複数のスキーマから個々のオブジェクトにすべてエクスポートされます。プロジェクト・エクスポートを使用する前に、変更を取得するための新しいブランチを作成します。

DEVで変更されたハード・オブジェクトは、プロジェクト・エクスポート・コマンドを使用してエクスポートする必要があります。これにより、ファイルの一番下にあるJSONコメントにあるオブジェクトのSXML表現が最新の状態に保たれます。そのSXMLは、次のステップでプロジェクト・ステージ・コマンドで使用されます。

ソフト・オブジェクトに関して、オブジェクトがデータベース(リポジトリの外部)で直接変更された場合は、オブジェクトをリポジトリにエクスポートする必要があります。ただし、srcディレクトリ内のファイルを変更し、オブジェクトをDEV DBにコンパイルした場合、リポジトリ内のコンテンツとしてオブジェクトをエクスポートする必要はなく、DEV DBはすでに同期しています。

ステップ3:Liquibase変更ログ/セットの作成(distディレクトリ)

ステップ3では、ターゲット・データベース上のアプリケーション・スキーマの移行に使用する、順序付けされた不変のSQL文セットを作成します。distは、srcの状態に正しく到達する操作の順序と考えてください。これは、srcとdistの間に関係があり、同期を維持する必要があることを意味します。dist中のファイルは、次の理由から有利です。

Liquibaseを活用して、ターゲット・データベースで実行される内容を追跡します。これにより、文がすでに実行されているかどうかを検出するための追加のコードなしで、SQLをクリーンに保つことができます。
これにより、操作の順序(SQL文が実行される順序)を完全に詳細に制御できます。これは、メインの変更ログ・オーダーのリリース、変更ログ・オーダーの変更のリリース(トラッキング・システムでチケットを考える)、変更ログがSQL文をオーダーする3レベルの階層変更ログ・システムを介して実現されます。外観は次のとおりです。
すべてのオブジェクトがバージョニングされます。つまり、依存オブジェクトが将来変更されても、カスタムSQLは破損しません。これにより、インストーラはアプリケーションの任意のバージョンから最新のバージョンに安全に移動できます。

project stageコマンドは、distディレクトリの管理に関連する作業の多くを自動化します。プロジェクト・ステージを実行すると、現在のブランチ内のsrcディレクトリの状態と別のブランチ(通常はmain)の状態が比較されます。比較の結果に基づいて、srcの古い状態から新しい状態に移行するために必要なLiquibase変更ログと1つ以上の変更セット(Liquibase形式のSQLファイル)が生成されます。これらのファイルは、dist/releases/next/changesの新しいディレクトリに作成されます。nextは現在のスプリントを表します。新しいディレクトリの名前は、現在のブランチ名に基づきます。

生成された変更セットは可能なかぎり最適な順序で並べられますが、開発者は変更ログ内の関連インクルード行を上下に移動することで順序を変更できます。生成された変更セットを変更する必要がある場合や、追加のSQLを追加する必要がある場合があります。

プロジェクト・ステージのadd-customコマンドを使用して、任意のカスタムSQLを変更に簡単に追加できます。このコマンドは、変更フォルダにプレースホルダ・ファイル(Liquibase関連のコメントを含む)を作成し、新しいファイルを指す変更ログの最後に新しいインクルードを追加します。SQLを追加し、インクルードを正しい操作順序に移動するだけで済みます。

ステップ4: テストDBでのLiquibase変更ログ/セットのテスト

このステップは、レポに進む品質を保証することです。この時点で検討できるテストには、様々なタイプがあります。

インストーラのテスト- 変更はDEV DBからエクスポートされ、DistでLiquibase変更ログ/セットの生成に使用されたため、同じデータベースをこのテストに使用できません(つまり、列がすでに存在する場合、列を追加する文は失敗します)。開発者は、新しい変更の直前に、最新の状態のDBでテストする必要があります。
機能/バグ修正テスト- インストーラが終了しても、機能またはバグ修正が完了したわけではありません。たとえば、開発者が新しい表の追加を忘れた場合、インストーラは正常に完了できますが、アプリケーションが使用しようとすると失敗します。これらのテストは、手動で実行することも、統合およびエンドツーエンドのテストを介して自動化することもできます。
標準テスト- 開発チームは、開発者がコードを記述する方法に関する標準をいくつでも持つことができます。標準ツールは、コードをスキャンし、あらゆる逸脱について報告することができます。
ユニット・テスト- ユニット・テストは、ビジネス・ロジックが存在する場所によって異なります。私のようにして、PL/SQLコードに多くのロジックを入れると、utPLSQLはコードベースが適切に機能するようにするための優れたツールになります。
セキュリティ・テスト- セキュリティ問題のソース・コードをスキャンするために使用できる様々なセキュリティ関連ツールがあり、複数のセキュリティ関連ツールを使用できます。コードが出荷される前に、常に脆弱性(SQLインジェクション、XSSなど)を見つける方が適切です。
負荷テスト- アプリケーションが妥当なワークロードに対応できるかどうかを確認する唯一の方法は、負荷の高い状態でテストすることです。

テストの実行時期と実行方法はプロジェクトによって異なります。考慮すべきタイミングの1つは事前PRです。これは、さらにダウンストリームを捕捉した場合に解決に時間がかかる問題を排除するのに役立ちます。少なくとも、開発者はインストーラをテストし、PRを作成する前に機能/バグ修正が機能することを確認する必要があります。

可能な場合はテスト用の自動パイプラインを実装し、新しいPRの作成時、マージの完了時、またはその両方がトリガーされる可能性があります。重大なテストが失敗した場合は、PRのマージがブロックされることが理想的です。

ステップ5: 変更をリポジトリにマージ

テストに合格すると、PRを作成する準備が整います(前のステップで行われなかった場合)。上級開発者はPRを確認し、開発者が以前に行ったテストの一部を繰り返し、最終的にコードをリポジトリにマージする必要があります。マージする前に何かを修正する必要がある場合は、PRを拒否して、コードがマージされる準備ができるまで、開発者は前述のステップを繰り返すことができます。

バリエーションの処理

記述されたプロセスはSQLclプロジェクトの意図した用途ですが、チームはそれをニーズにあわせて適応させることができます。たとえば、一部のチームは、スプリントの終了までプロジェクト・ステージの実行を遅延する場合があります。これにより開発が簡素化される可能性がありますが、カスタムDMLの正しい順序付けを忘れるなどの問題が発生する可能性があります。バリエーションを試す前に、標準的なプロセスから始めることをお勧めします。

まとめ

SQLcl Projectsは、開発データベースの変更から、リポジトリへの更新のテストおよびマージまで、Oracle Databaseアプリケーションの開発ライフサイクルを管理するための堅牢なフレームワークを提供します。構造化されたプロセス(ソース・ファイルの同期、Liquibase変更ログの生成、変更の厳密なテスト)に従うことで、チームはデータベース更新が効率的で信頼性が高く、メンテナンス性が高いことを確認できます。このアプローチは、コラボレーションを簡素化するだけでなく、アプリケーション・ライフサイクル全体で一貫性と品質を促進します。SQLclプロジェクトについてさらに詳しく調べると、これらの基本的なステップは、合理化および標準化されたデータベース開発の可能性を最大限に活用するのに役立ちます。

詳細はこちらこのプレゼンテーションを見て、クイック・スタート・ガイドで作業します。SQLclフォーラムで質問することを忘れないでください。