SQLclとLiquibaseによるOracle Database CICD - Part 1 (2022/07/31)
SQLclとLiquibaseによるOracle Database CICD - Part 1 (2022/07/31)
https://blogs.oracle.com/database/post/part-1-oracle-database-cicd-with-sqlcl-and-liquibase
投稿者： Brian Spendolini | Oracle Database Development Tools Product Manager
第1回：Oracle Databaseで継続的インテグレーションを始める方法
CI/CDとは
継続的インテグレーション（CI）と継続的デリバリー/デプロイメント（CD）は、ウォーターフォールモデルなどの従来のソフトウェア開発と比較して、より速く、より確実に、より少ないバグでコードを提供するために開発チームを強化する一連の原則または方法論です。CI/CDを使用するチームは、通常、アジャイル手法のいくつかのバージョンに準拠しており、数ヶ月または数年にわたる一枚岩のタスクではなく、スプリントでより大きな包括的要件の一部として小さな機能に取り組んでいます。
また、アジャイル手法と、クラウド上でコードとしてインフラを迅速に作成する能力が衝突したことで、DevOps（開発者オペレーション）が出現しました。これらのチームが新しい開発環境を調査するにつれ、もはやこれまでのように自分たちの世界だけで仕事をすることは不可能であることが明らかになったのです。従来の仕事の役割が曖昧になり、より少ない人数でより多くの仕事をこなすようになると、この新しい複雑性のカオスから秩序を生み出す必要がありました。
では、CI/CDとは何でしょうか？開発者、運用担当者、そしてソフトウェアに機能や特徴を持たせる必要のある関係者が入り乱れている中で、CI/CDはどのような役割を果たすのでしょうか。その答えとして、CI/CDのCIである継続的インテグレーションから始めましょう。
継続的インテグレーションは、1つのプロジェクトで複数の開発チームと運用チームが同時に異なる機能に取り組む際に、お互いを踏みつぶすことなく作業できるようにする機能をもたらすものです。この前提はあまりに真実味がないように聞こえますが、ここにもいくつかの真実があります。
常に参照できる共通のスレッドを持つために、この一連の投稿では、これから話すコンセプトとプロセスを説明するために、実際のコードの背後にある共通の例を使用します。それでは、開発プロセスを構築する際に参照できるような例を使って、すぐに本題に入りましょう。
私たちのシナリオはこうです。ある開発チームが、市のウェブサイト上のウェブインターフェースを介して、地域の木を追跡するアプリケーションに取り組んでいます。市民はこのアプリにアクセスし、市内で見つけた歴史的な樹木の情報を入力することができます。今、このチームはアジャイル手法も使っていて、次のスプリントの時期が来ています。主に地図上で樹木を確認できる機能や、樹木の入力フォームと一緒に写真をアップロードできる機能など、いくつか盛り込まなければならない機能があるのです。開発者にタスクが割り当てられ、スプリントがスタートします。
継続的インテグレーションはいつ始まるのですか？タスクが配られると、各開発者はリポジトリにある最新のリリースからコードをコピーし、自分自身のコピーまたはブランチを作成します。この最新のコードリリースは、現在本番環境でデプロイされ動作しているコードの正確なコピーです。また、各開発者には個人用の開発データベースが与えられますが、これについては後で詳しく説明します。開発者は、割り当てられた作業を終えると、自分のコードブランチをリポジトリにコミットします。プルリクエストやマージを行う前に、リポジトリにある現在のメインブランチコードに、他の開発者がマージしたきれいなコードブランチからの変更がないかどうかを確認します。もし見つかったら、これらの変更を取り下げ、自分のコードを再度コミットします。これらの変更のうちのひとつが、自分たちのコードに悪影響を及ぼしている可能性があり、プルリクエスト/マージが発生したときに行われるビルドプロセスがこれを捕捉します。コードレビューが予定されており、それが承認されると、開発者はプルリクエスト/マージをメインブランチに作成できるようになります。また、コードが main ブランチにマージされるたびにビルドプロセスが実行され、バグや問題、あるいは他の開発者のコードが原因で発生した問題などが検出されます。もし問題があれば、それに対処し、プルリクエスト/マージが作成され、再び自動テストが行われます。テストに問題がなければ、そのコードは main ブランチにマージされます。
まとめポイント
- スプリントの開始
- メインからコードをプル
- ローカルブランチの作成
- チケット/機能に関する作業
- メインブランチの更新を確認する
- ブランチのコミット
- マージ要求の作成
- コードレビュー
- メイン/最新リリースへのマージ
このプロセスによって、私たちはどのようなメリットを得ることができるのでしょうか。まず、このプロセスを通してわかるように、本番環境に入る前に問題をキャッチすることができます。コードの変更に対して自動テストを実行することで、デプロイ時に何が起こるかをシミュレートし、予期せぬ事態を排除することができるのです。これは、より良いリリース、ステークホルダーやエンドユーザーからの開発チームへの信頼、そして開発者のより高いコード水準につながります。
説明責任も重要な要素です。私たちは、コードのコミット、マージ、レビューを通じて、誰が何をコード・リポジトリに入れたかを正確に把握することができます。マージ時に各ファイルとコード行をレビューできるため、コードのサプライチェーンの問題やハッキングを発見することができます。また、最新のコード・リポジトリでは、いつ、誰が、どのような変更を行ったかを追跡できるため、常に履歴を残すことができます。
ステートレス vs. ステートフル
継続的インテグレーションは、ステートレスなファイルとデプロイメントで非常にうまく機能します。Java クラスや JavaScript などの静的ファイルとステートレスなコンテナ デプロイメントを組み合わせると、新しいものが入ってきて古いものが出ていくことになります。ステートレス・ファイルを扱う場合、最新のコードを含む新しいデプロイメントを docker コンテナ内に作成し、古いコンテナを置き換えることは非常に簡単です。
これは、ブルーグリーンデプロイメントモデルで見られることです。このモデルでは、実行中のアプリケーションコンテナ（青）があります。緑色は、新たにデプロイされたアイドル状態のアプリケーション・コンテナです。ある時点で緑色に切り替えると、すべてのトラフィックが新しいバージョンを使用するようになり、青色のコンテナはアイドル状態になっています。ロールバックやスイッチバックが必要な場合は、アイドル状態の青いコンテナに戻せばよいのです。
このようなモデルは、データベースのデプロイには向かないことがすぐにわかります。データベースには状態があり、トランザクションは常にコミットされているため、データベース全体をコピーして変更をデプロイし、その後オペレーションを再開するためのダウンタイムが確保できない限り、これは困難な課題となります。このため、DBAやデータベース開発者は、このような導入のボトルネックについて非難されることが非常に多いのです。データベースはCI/CDはおろかDevOpsもできない、レガシーすぎる、とよく言われます。DBAとデータベース開発者はどうなるのでしょうか？彼らはレガシーという烙印を押され、CI/CDの障害とみなされるでしょう。
商売道具
すべてのデータベースのデプロイを簡単にし、ステートレスCD/CDフローに直接組み込むことができる魔法の杖があればいいのですが、DevOpsの懸念には真実があることを認めざるを得ません。しかし、すべての希望が失われたわけではありません。Oracle DatabaseのCI/CDは実現可能ですが、従来の方法論やプロセスを若干変更し、さらにOracle Databaseのこれまで使われてこなかった特徴や機能を使った新しいトリックが必要です。
プロセスフローを参照し、データベース開発に特化したステップを追加することができるか見てみましょう。
スプリントが始まり、私たちはデータベース開発者に最新のリリースから最新のコードを引っ張ってこさせます。このコードはどこにあるのでしょうか？開発者がデータベースのコードのローカルコピーを持てるようにするには、どんなツールを使えばいいでしょうか？私たちはコードリポジトリを使用しています。
コードリポジトリとは何ですか？
Git、GitHub、GitLab、BitBucketなど、多くのコードリポジトリがあります。これらのリポジトリは、私たちがファイルを保存し、バージョン管理、説明責任、開発プロセスの可視性を提供するのに役立ちます。しかし、私たちはゼロからのスタートです。リポジトリもコードリリースもありません。そこで、Change Management/Tracking toolを使ってベースラインを作成する必要があります。
Oracleでどのように変更管理/トラッキングを行うことができますか？
Liquibase と一緒に SQLcl を利用します。
SQLclとは?
Oracle SQLcl (SQL Developer Command Line) は Oracle Database のための小さく、軽量な Java ベースのコマンドラインインタフェースです。SQLcl は、インライン編集、文の補完、コマンドの呼び出しなどを提供し、既存の SQL*Plus スクリプトもサポートします。SQLclは、oracle.comからダウンロードすることができ、デフォルトでOCI Cloud Shellにインストールされています。
Liquibase とは?
Liquibase は、データベースのスキーマ変更を追跡、管理、適用するためのオープンソースのデータベース非依存型ライブラリです。
どのように連携するのですか?
SQLcl の Liquibase 機能は、単一のオブジェクトやフルスキーマの変更ログを生成するコマンドを実行することができます (変更セットと変更ログ)。また、SQLcl の Liquibase に Oracle 固有の機能と拡張を追加しています。
どんなデータベース?
この記事では、Oracle Databaseで稼働するための最も簡単な方法は、無料の OCI アカウントとAlways Freeの Autonomous Database です。これらは数分で立ち上がり、使用料がかかることはありません。もし、まだOCIアカウントをお持ちでない場合は、ここから始めることができます。アカウントにログインしたら、こちらのガイドに従って、いつでも無料でAutonomous Databaseを作成することができます。ここでは、Autonomous Transaction Processingデータベースで問題ありません。データベースを作成する際に使用したパスワードは、後で必要になりますので、忘れないようにしてください。
いや、本当に、どんなデータベース？
この記事の例では単一のAutonomous Databaseを使用しますが、現実世界ではいくつかの選択肢があります。しかし、最も重要なことは、すべての開発者は作業用に個人用データベースを持たなければならないということです。これは多くの要因から難しいかもしれませんが、ここでは開発組織でこのステップを実現するためのいくつかの提案をします。
1）Oracle Databaseでマルチテナントを利用する
19c以降では、プラグインデータベースを3つまで無料で利用できることをご存知でしょうか？マルチテナントライセンスは不要で、作って使うだけ。PDB（プラガブル・データベース）には、オリジンPDBからメタデータだけをクローンする機能もあります。これにより、すべての開発者のためのプロダクションコード・データベースのコピーを作成するのが非常に簡単になります。また、次回の記事で説明するテストの自動化プロセスにも役立ちます。また、データベースにOracle REST Data Services（ORDS）をインストールすることで、RESTコールによるPDBのクローンや作成のためのAPIが利用できるようになることも、簡単にメモしておきます。
2）OCIにおけるAutonomous Database
OCIでのADBの利用は、マルチテナントと非常によく似ており、任意のADBの完全なクローンやメタデータのみのクローンを作成することができる。また、これらのADBインスタンスは、数分から数週間のみ稼働させる必要があります。
3) 再利用可能なインスタンス
Oracle Databaseには、開発者がマルチテナントではないインスタンスで作業するためのクリーンスレート（白紙状態）を回復するための機能がたくさんある。Guaranteed Restore Points/Flashback Database、RMAN duplicates/clones 、Data Pumpなどの機能により、スプリント開始時に各開発者用のクリーンなインスタンスを用意することができます。
4) Docker/仮想マシン
クラウドベースでもローカルでも、仮想化技術によって、開発者はメインのコードリポジトリのコピーを含む個人用インスタンスで作業することも可能です。また、開発者は、必要であれば、本番インスタンスの最終バックアップに基づいて、OCI のデータベースの VM インスタンスを作成し、個人的なデータベース作業を支援することができます。
Hello Repo
もう一度、プロセスフローと例を参照して、開発者全員が同じコードから始められるように、ベースラインまたはメインリリースを作成する必要があります。これを行うには、SQLcl と Liquibase を使用する必要があります。
必要なセットアップ
これから説明する例では、SSH 鍵を事前に設定し、GitHub にリポジトリを置き、プロジェクト名を db-cicd-project として、コマンドラインから git を使用します。
ここで2つの選択肢があります。
手動でリポジトリを作成するか、この記事のためにあらかじめ作成されているリポジトリをフォークするかです。私はここからフォークすることをお勧めします。
https://github.com/Mmm-Biscuits/db-cicd-project
次に、以下のドキュメントでSSH接続の設定を行います。
SSHでGitHubに接続
GitHubのデスクトップGUIも用意されています。
ここで、ローカルのマシン/コンピュータ/ノートパソコンにクローンする必要があります。git リポジトリをローカルに保存したいディレクトリに移動し、clone コマンドを実行します。
> git clone git@github.com:YOUR_GITHUB_USERNAME/db-cicd-project.git
上記のコマンドはあなたのためにdb-cicd-projectというディレクトリを作成し、リポジトリにあったコードをすべて引き出します。さて、このリポジトリをデータベースの良さで満たす時が来ました。
最初の Genschema
以下のリポジトリディレクトリ構造は、あなたがフォークしたサンプルリポジトリが含んでいるものです。
db-cicd-project
- apps
- database
- etc
- presetup
- setup
- postsetup
- static
- css
- html
- images
- js
- ut
- utPLSQL
- README.md
- version.txt
注：このディレクトリ構造は、いくつかのことを想定しています（想定が何をもたらすかは周知のとおりです）。apps ディレクトリには Application Express アプリが含まれる可能性があるため、サブディレクトリはたとえば f101 のようになることを想定しています。APEX を使用しない場合は、静的ディレクトリと apps ディレクトリを 1 つのディレクトリに統合することができます。
このディレクトリ構造を使って、これからデータベースとSQLclを操作していきます。無料のADBを使用して、SQLclがデータベースに接続するためのすべての情報を含むウォレットをダウンロードする必要があります。ウォレットをダウンロードする手順は、こちらをご覧ください。
ADBウォレットをダウンロードしたら、コマンドラインで、ディレクトリをリポジトリプロジェクト内のデータベースディレクトリに変更します。db-cicd-project->databaseにあるはずです。SQLclを起動しますが、データベースにはまだログインしないでください。
> sql /nolog
次に、SQLclにADBウォレットを探す場所を指示する必要があります。まず、ダウンロードした場所を覚えておいて、以下のコマンドでその場所を設定します。
SQL> set cloudconfig /DIRECTORY_WHERE_WALLET_IS/WALLET.zip
ウォレットの命名は、Wallet_DB_NAME.zipという形式です。つまり、データベースをADBと名付けた場合、ウォレット名はWallet_ADB.zipとなります。そして、ウォレットをダウンロードフォルダに入れ、フルコマンドで実行すると、こうなります。
SQL> set cloudconfig /Users/bspendol/Downloads/Wallet_ADB.zip
次に、データベースに接続する必要があります。構文は次のとおりです。
SQL> conn USERNAME@DB_NAME_high/medium/low/tp/tpurgent
high/medium/low/tp/tpurgentは、データベースに接続する様々なクライアントやアプリケーションに対して、異なるレベルのパフォーマンスを提供します。ドキュメントより
- tpurgent：タイムクリティカルなトランザクション処理操作のための、最も優先度の高いアプリケーション接続サービスです。この接続サービスは手動並列処理をサポートします。
- tp：トランザクション処理操作のための標準的なアプリケーション接続サービス。この接続サービスは、並列化で実行されません。
- high：レポートやバッチ処理用の高優先度アプリケーション接続サービス。すべての操作は並列で実行され、キューイングが適用されます。
- medium：レポートやバッチ処理用の標準的なアプリケーション接続サービス。すべての操作は並列に実行され、キューイングされます。このサービスを使用すると、並列処理の程度は 4 つに制限されます。
- low：レポートやバッチ処理操作のための最も低い優先度のアプリケーション接続サービス。この接続サービスは並列で実行されません。
私たちがやりたいことについては、ハイパフォーマンスなサービス名で問題ないでしょう。また、スキーマとそのスキーマに対する権限を設定できるように、adminユーザーとして接続したいと思います。データベース名をADBとすると、次のような接続コマンドになります。
SQL> conn admin@ADB_high
そして、パスワードプロンプトでADB作成時に使用したパスワードを入力します。
Password? (**********?)
そして、私たちはその中にいます。スキーマを作成し、スキーマに権限を与え、Liquibase を利用するためのサンプルをセットアップする時間です。次のコマンドを実行します。
SQL> create user demo identified by "PAssw0rd11##11" quota unlimited on data;
SQL> grant connect, resource to demo;
今度はこのユーザーで接続してください。
SQL> conn demo@ADB_high
そして、パスワードのプロンプトでパスワードを入力します。
Password? (**********?)
それでは、サンプルリポジトリのデータベースオブジェクトを作成しましょう。サンプルリポジトリに含まれる以下のスクリプトを実行して、いくつかのオブジェクトを作成します。
SQL > @../demo_scripts/create_table.sql
SQL > @../demo_scripts/insert_data.sql
SQL > @../demo_scripts/create_logic.sql
これは、テーブル、テーブル内のデータ、ロジック付きトリガー、2つのプロシージャを作成しました。これが、これから作成するアプリケーションのベースラインだとします。それでは、Liquibase を使ってベースラインを作成し、リポジトリにコミットしてみましょう。
SQL プロンプトで、次のコマンドを実行します。
SQL> lb genschema -split
これが終わったら、SQLcl を終了し、リポジトリへの変更のコミットを開始します。
SQL> exit
データベースディレクトリをざっと見てみると、インデックス、テーブル、プロシージャ、トリガなど、先ほど作成したすべてのオブジェクトのフォルダがあることがわかると思います。また、controller.xml ファイルもあります。このファイルは、スキーマを他のデータベースやCIプロセスに正しくデプロイできるように、各ディレクトリにあるすべてのファイルを適切な順序で含む変更ログです。
私たちのコードをリポジトリにコミットする時が来ました。ディレクトリをプロジェクトのトップレベル(db-cicd-projectディレクトリ)に変更し、以下のコマンドを実行してください。
> git add .
このコマンドは、新しいファイルをローカルのステージングエリアに追加します。次に、ファイルをコミットします。
> git commit -m "v1.0"
git commit は、ローカルリポジトリのスナップショットを取得するもので、現在の状態を保存すると考えてもよいでしょう。最後に、これらのファイルを GitHub のファイルリポジトリにプッシュしましょう。
> git push
push コマンドは、コミットや状態をメインリポジトリにアップロードします。プッシュが完了したら、GitHub のリポジトリにあるファイルを見ることができます。これで、ベースライン (バージョン 1.0) の作成は完了です。
Ready, Set, Branch
これで、アプリケーションのメインとなるコードラインがリポジトリに登録されました。これで、開発者にリポジトリをクローンしてもらい、この開発サイクルやスプリントで割り当てられたチケットやタスクを開始することができます。この場合の問題は、開発者全員がメインにコミットしてしまい、おそらくお互いを踏みつけにしてしまうことです。そのため、各開発者はリポジトリに自分のブランチを作成し、そこで作業したりコードをコミットしたりする必要があります。
リポジトリをクローンするための URL を渡され、コーディングを開始した開発者の場合を考えてみましょう。彼らはまず git を使って自分のローカルマシンにクローンします。
> git clone git@github.com:YOUR_GITHUB_USERNAME/db-cicd-project.git
今度は、このコードの個人用ブランチを作成する必要があります。
> git checkout -b BRANCH_NAME
良い習慣としては、開発者が作業しているチケットやスプリントと関連付けるために、ブランチに名前を付けてもらうことです。以下に例を示します。
> git checkout -b TICKET#_USERNAME
> git checkout -b JIRA_TICKET#_USERNAME
> git checkout -b SPRINT#_USERNAME
ここでの例では、次のようにしましょう（私ではなく、あなたの名前を使いましょう）。プロジェクトの最上位フォルダ（db-cicd-project）で、このコマンドを実行します。
> git checkout -b sprint1_brian.spendolini
そして、その手応えを実感してください。
> Switched to a new branch 'sprint1_brian.spendolini'
これで、メインコードに変更を加えることなく開発を始め、リポジトリにコードをコミットできるようになりました。自分がどのブランチにいるのかを確認するには、いつでも git status を発行することができます。
> git status
On branch sprint1_brian.spendolini
nothing to commit, working tree clean
変更点のみ
スプリントに戻りましょう。例のシナリオを覚えているなら、最初のチケットは、市民が入力する木の写真をアップロードできるように、木のテーブルに新しいカラムを追加する必要があると言っています。よし、簡単な作業ですね。
db-cicd-project プロジェクトのローカル git リポジトリに移動したら、データベースディレクトリに移動します。そして、前と同じように、SQLcl を使ってAutonomous Databaseにログインします。
> sql /nolog
ウォレットの場所を再度設定します（ディレクトリのパスが異なります）。
SQL> set cloudconfig /Users/bspendol/Downloads/Wallet_ADB.zip
そして、データベースに接続します。
SQL> conn demo@ADB_high
And then provide the password at the password prompt (password is PAssw0rd11##11):
Password? (**********?)
カラムを追加する時間です。以下のSQLを発行して、treesテーブルにpersonal_interestカラムを追加することができます。
SQL> alter table trees add (tree_picture blob);
Table TREES altered.
チケットが完成したら、Liquibase を使ってスキーマを再度生成します。
SQL> lb genschema -split
SQLclを終了し、ローカルのgitリポジトリのトップレベルに戻ることができます。db-cicd-projectで、git addを発行します。
> git add .
そして、コミット
> git commit -m "ticket1"
そして、新しいコードをリポジトリにプッシュします。このプッシュは、ブランチにプッシュするため、少し異なります。git push を実行すると、以下のような画面が表示されます。
> git push
fatal: The current branch sprint1_brian.spendolini has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin sprint1_brian.spendolini
そこで、今回だけはブランチでプッシュを発行する必要があります。
> git push --set-upstream origin sprint1_brian.spendolini
GitHubのWeb UIにアクセスすると、このリポジトリでは新しいブランチが作成され、テーブルファイルだけが期待通りに更新されていることがわかります。
プロシージャとトリガーコードを含む他のファイルは変更されていません。ここでも Liquibase は私たちのために変更を追跡しています。
適用
マスターコードの行をデータベースのスキーマに適用し、新しいブランチを適用して、Liquibase が何を行うか見てみましょう。
ローカルマシンのローカルコードリポジトリにある master ブランチに戻る必要があります。その前に、この切り替えをしたときに何が起こったかを見てみましょう。コミットしたブランチにいる間に、データベースディレクトリに移動してください。trees_table.xml ファイルを見てみましょう。XML に新しいカラムが追加されているのがわかると思います。
<COL_LIST_ITEM>
<NAME>TREE_PICTURE</NAME>
<DATATYPE>BLOB</DATATYPE>
</COL_LIST_ITEM>
ここで、以下のgitコマンドを実行します。
> git checkout master
そして、もう一度 trees_table.xml を見てください。このファイルの最後のカラムはSUBMISSION_DATEで、もはやTREE_PICTUREではないことがわかると思います。
<COL_LIST_ITEM>
<NAME>SUBMISSION_DATE</NAME>
<DATATYPE>TIMESTAMP</DATATYPE>
<SCALE>6</SCALE>
</COL_LIST_ITEM>
なぜでしょうか？それは、あなたがブランチを master ブランチに切り替えて、そこに私たちの基本コードを置いたからです。このコードはまだメインブランチにマージされていないので、新しいカラムの変更は開発用ブランチにしか存在しません。そこで、この利点を活かしてみましょう。master ブランチにいる間に SQLcl を起動し、admin ユーザーでログインします。
> sql /nolog
SQL> set cloudconfig /Users/bspendol/Downloads/Wallet_ADB.zip
SQL> conn admin@ADB_high
そして、新しいスキーマを作成します。
SQL> create user test identified by "PAssw0rd11##11" quota unlimited on data;
SQL> grant connect, resource to test;
SQL> conn test@ADB_high
Password? (**********?) **************
Connected.ローカルプロジェクトのデータベースディレクトリにいる必要があります。もしまだそこにいなければ、SQLclに組み込まれた機能のいくつかを使ってそこに行くことができます。cdコマンドでディレクトリを移動することができます。データベースディレクトリの下のテーブルディレクトリにいる場合は、単純に
SQL> host cd ..
そして、プロジェクトホームのデータベースディレクトリにディレクトリを移動してください。また、SQLclでhostコマンドを使えば、現在地を確認することができます。
SQL> host pwd
/Users/bspendol/git/db-cicd-project/database
あなたが /db-cicd-project/database ディレクトリにいることを確認し、私なら上記のようにします。
/Users/bspendol/git/db-cicd-project/database にあることを確認します。
ディレクトリ内のファイルを見るために、host lsコマンドを発行することもできます。
SQL> host ls
controller.xml index table
database_files_here procedure trigger
controller.xml ファイルを使用することを検討しています。
簡単なチェックポイント 先ほど作成したテストユーザでデータベースにログインし、ローカルリポジトリの master コードブランチにいて、プロジェクトホームのデータベースディレクトリにいます。ここで、Liquibase を使って master ブランチからオブジェクトを作成します。次のコマンドを実行します。
SQL> lb update -changelog controller.xml
このコマンドを発行すると、すべてのオブジェクトがデータベースに作成されるのが確認できます。
SQL> lb update -changelog controller.xml
ScriptRunner Executing: table/trees_table.xml::96726c6d630653c9a9169df8b67089f2cdee1135::(DEMO)-Generated -- DONE
ScriptRunner Executing:
procedure/admin_email_set_procedure.xml::9d1175a5b6ca6d0c969a2eb183062e0a873ee226::(DEMO)-Generated -- DONE
ScriptRunner Executing: index/tree_id_pk_index.xml::b4dd6c2359e7f1e881b55ba728056510d537967a::(DEMO)-Generated -- DONE
ScriptRunner Executing: trigger/set_date_bi_trigger.xml::3b0d8da4c19a11b80f035a748c9b40752f010110::(DEMO)-Generated -- DONE
######## ERROR SUMMARY ##################
Errors encountered:0
######## END ERROR SUMMARY ##################さて、開発ブランチに移動して、このスキーマに適用してみましょう。SQLclから退出します。
SQL> exit
ブランチを変更する（あなたのブランチは違う名前になることを忘れないでください。同じ名前の私のクローンでない限り、ブランチは違う名前になります。）
> git checkout sprint1_brian.spendolini
Switched to branch 'sprint1_brian.spendolini'
Your branch is up to date with 'origin/sprint1_brian.spendolini'.
そして、このテストユーザーとしてデータベースにログインし直してください。
> sql /nolog
SQL> set cloudconfig /Users/bspendol/Downloads/Wallet_ADB.zip
SQL> conn test@ADB_high
そして今度は、開発ブランチを使用して、このスキーマに変更を適用します。
SQL> lb update -changelog controller.xml
ScriptRunner Executing: table/trees_table.xml::f81a149311b20a5a1dfe95a35108b8728df33b7f::(DEMO)-Generated -- DONE
######## ERROR SUMMARY ##################
Errors encountered:0
######## END ERROR SUMMARY ##################Liquibase は、DATABASECHANGELOG と DATABASECHANGELOG_ACTIONS という二つのテーブルを使って変更を追跡しています。また、これらのテーブルを組み合わせた、より読みやすい形式の DATABASECHANGELOG_DETAILS というビューがあります。DATABASECHANGELOG_DETAILSビューを見てみると、テーブルの変更のみが行われ、SQL列でテーブルを削除して再作成したわけではないことがわかります。
SQL
--------------------------------------------
ALTER TABLE "TREES" ADD ("TREE_PICTURE" BLOB)
これは、例えば本番環境での動作だけでなく、より重要なこととして、変更管理ツールが実行することを想定した動作でもあります。
Merge Ahead
これで、開発グループや組織のために、SQLcl、Liquibase、git リポジトリで変更管理を始めるためのツールを手に入れました。すべての新しいプロセスと同様に、ゆっくりと始めてください。たとえば、git を使って中央のリポジトリにコードをコミットすることに慣れるところから始めるとよいでしょう。しかし、いったんこれらの構成要素を追加し始めると、CICDの道を次の段階へと進んでいくことができます。
このプロセスでは、データベースのスプリントコードとステートレスアプリケーションのコードを同じリポジトリで組み合わせ、開発チーム全体のCICDプロセスを設定することも可能です。データベース開発者とDBAは、もはやレガシーと呼ばれて冷遇されるのではなく、他の開発チームが享受してきたのと同じ変更管理とリポジトリの実践を取り入れることができるようになったのです。
Part 2では、このコードのテストに使うべき自動化されたパイプラインについて説明します。要するに、コミットやマージ要求が発生したら、新しいデータベースでコードをテストするのです。
コメント
コメントを投稿