Liquibaseを使用して足への銃撃を避ける方法

これまでにないこと、そしてまたやります!

次のプロジェクトでは、将来の問題を避けるために最初から Liquibase を使用することにしました。 結局のところ、若いチームメンバー全員がその正しい使い方を知っているわけではありません。 社内ワークショップを開催し、それを記事にすることにしました。

この記事には、役立つヒントと、リレーショナル データベース移行ツール、特に Liquibase を使用するときに陥りやすい XNUMX つの最も明白な落とし穴についての説明が含まれています。 初級および中級レベルの Java 開発者向けに設計されており、より経験豊富な開発者にとっては、おそらくすでに知られている内容を構造化して繰り返すのに興味深いものとなるでしょう。

Liquibase と Flyway は、Java の世界におけるリレーショナル構造のバージョン管理の問題を解決するための主要な競合テクノロジです。 最初のものは完全に無料であり、実際に使用するために最も頻繁に選択されます。それが、Liquibase が出版物の主人公として選ばれた理由です。 ただし、説明されている実践方法の一部は、アプリケーションのアーキテクチャによっては普遍的なものになる場合があります。

リレーショナル構造の移行は、リレーショナル データ ストアの弱い柔軟性に対処するための強制的な方法です。 OOP 流行の時代、データベースを扱うスタイルは、スキーマを一度記述すれば、その後は触れないことを意味していました。 しかし、現実には状況は常に変化しており、テーブル構造の変更が頻繁に必要になります。 当然のことながら、そのプロセス自体は苦痛で不快なものである可能性があります。

プロジェクトにライブラリを追加するためのテクノロジと手順についてはこれ以上詳しく説明しません。このトピックに関しては、かなりの数の記事が書かれています。

• Liquibase を使用して Spring Boot アプリケーションのデータベース構造を管理します。 パート1
• Liquibase を使用して Spring Boot アプリケーションのデータベース構造を管理します。 パート2
• Liquibase と Maven
• データベース変更のバージョン管理へのアプローチ
• Spring MVC/Security、REST、Hibernate、Liquibase を XNUMX 行で起動します

さらに、役立つヒントに関する優れた記事がすでにありました。

• 頭痛のない Liquibase の使用。 実際の開発経験から得た 10 のヒント

Советы

移民の問題を解決するために汗と血と痛みを経験して生まれた私のアドバイスとコメントを共有したいと思います。

1. 作業を開始する前に、次のベスト プラクティスのセクションをよく理解しておく必要があります。 オンライン リキベース

Там シンプルですが非常に重要なことが説明されており、これがないとライブラリの使用が複雑になる可能性があります。 たとえば、チェンジセットを管理するための構造化されていないアプローチは、遅かれ早かれ混乱や移行の失敗につながるでしょう。 相互に依存する変更をデータベース構造とサービス ロジックに同時に展開しない場合、レッド テストや環境の破壊につながる可能性が高くなります。 さらに、公式 Web サイトの Liquibase の使用に関する推奨事項には、メインの移行スクリプトに加えてロールバック スクリプトの開発とテストに関する条項が含まれています。 さて、記事の中で https://habr.com/ru/post/178665/ 移行とロールバック メカニズムに関するコード例があります。

2. 移行ツールの使用を開始する場合は、データベース構造を手動で修正しないでください。

ことわざにあるように、「一度ペルシルは、常にペルシルです。」 アプリケーションのベースが Liquibase によって管理され始めると、手動で変更を加えるとすぐに矛盾した状態になり、変更セットの信頼レベルがゼロになります。 潜在的なリスクとしては、データベースの復元に数時間かかることや、最悪の場合、サーバーが停止することが挙げられます。 チームに「昔ながらの」DBA アーキテクトがいる場合は、彼が条件付き SQL 開発者からの独自の理解に従ってデータベースを編集した場合にどのような事態が起こるかを辛抱強く思慮深く説明してください。

3. 変更セットがすでにリポジトリにプッシュされている場合は、編集を避けてください。

別の開発者がプルを作成して変更セットを適用し、後で編集する場合、アプリケーションの起動時にエラーが発生したときに、その開発者は間違いなくあなたのことを覚えていて、親切な言葉をかけてくれるでしょう。 変更セットの編集が何らかの形で開発に漏れた場合は、ホットフィックスの滑りやすい坂道をたどる必要があります。 問題の本質は、Liquibase の主要なメカニズムであるハッシュ サムによる変更の検証にあります。 チェンジセット コードを編集すると、ハッシュ量が変更されます。 変更セットの編集は、データを失わずにデータベース全体を最初からデプロイできる場合にのみ可能です。 この場合、SQL または XML コードをリファクタリングすると、逆に作業が楽になり、移行が読みやすくなります。 例としては、アプリケーションの開始時にソース データベースのスキーマがチーム内で合意されている状況が挙げられます。

4. 可能であればデータベースのバックアップを検証してください

ここでは、すべてが明らかだと思います。 突然移行が失敗した場合は、すべてを元に戻すことができます。 Liquibase には変更をロールバックするツールがありますが、ロールバック スクリプトも開発者自身によって書かれており、メインの変更セットのスクリプトと同じ確率で問題が発生する可能性があります。 これは、どんな場合でもバックアップを使用して安全に対処することが役立つことを意味します。

5. 可能であれば、開発中に実績のあるデータベースのバックアップを使用します。

これが契約やプライバシーに反せず、データベースに個人データがなく、太陽 100 個分の重さもない場合は、ライブ マイグレーション サーバーで使用する前に、開発者のマシンでどのように動作するかを確認し、計算することができます。移行中の潜在的な問題はほぼ XNUMX% 解決されます。

6. チームの他の開発者とコミュニケーションをとる

適切に組織化された開発プロセスでは、チームの全員が誰が何をしているのかを把握しています。 実際には、これは当てはまらないことが多いため、タスクの一環としてデータベース構造の変更を準備している場合は、これについてチーム全体にさらに通知することをお勧めします。 誰かが並行して変更を加えている場合は、慎重に整理する必要があります。 仕事の始めだけでなく、仕事が終わった後にも同僚とコミュニケーションをとる価値があります。 チェンジセットに関する潜在的な問題の多くは、コード レビューの段階で解決できます。

7. 自分が何をしているのか考えてみましょう。

それはどんな状況にも当てはまる自明のアドバイスのように思えるでしょう。 しかし、開発者が自分が何をしていて、それが何に影響を与える可能性があるのか​​をもう一度分析していれば、多くの問題は回避できたはずです。 移行の作業には常にさらなる注意と正確さが必要です。

トラップ

次に、上記のアドバイスに従わない場合に陥る可能性のある典型的な罠を見てみましょう。具体的には何をすべきでしょうか?

状況 1: XNUMX 人の開発者が同時に新しい変更セットを追加しようとしています

Vasya と Petya は、お互いのことを知らずに、チェンジセット バージョン 4 を作成したいと考えています。 彼らはデータベース構造に変更を加え、異なる変更セット ファイルを使用してプル リクエストを発行しました。 次の作用機序が提案されています。

決め方

1. どういうわけか、同僚は変更セットを適用する順序について合意する必要があります。たとえば、Petin を最初に適用する必要があります。
2. 誰かが 5 番目の変更セットを自分自身に追加し、Vasya の変更セットをバージョン XNUMX でマークする必要があります。これは、Cherry Pick または適切なマージによって実行できます。
3. 変更後は、実行したアクションの妥当性を必ず確認する必要があります。
   実際、Liquibase メカニズムでは、リポジトリ内に 4 つのバージョン 4 変更セットを含めることができるため、すべてをそのままにしておくことができます。 つまり、バージョン XNUMX に対して、異なる名前で XNUMX つの変更が加えられるだけです。 このアプローチでは、後でデータベースのバージョンをナビゲートすることが非常に困難になります。

さらに、リキベースにはホビットたちの故郷と同様、多くの秘密が隠されています。 そのうちの 1.7 つは validCheckSum キーです。これはバージョン XNUMX で登場し、データベースに格納されている内容に関係なく、特定の変更セットに有効なハッシュ値を指定できるようにします。 ドキュメンテーション https://www.liquibase.org/documentation/changeset.html は次のように述べています。

データベースに何が保存されているかに関係なく、この変更セットに対して有効であるとみなされるチェックサムを追加します。 主に、changeSet を変更する必要があり、既に実行されているデータベースでエラーがスローされたくない場合に使用されます (推奨される手順ではありません)。

はい、はい、この手順はお勧めできません。 しかし、強い光の魔術師が闇の術を習得することもあります

状況 2: データに依存する移行

ライブサーバーからのデータベースバックアップを使用する機能がないとしましょう。 Petya はチェンジセットを作成し、ローカルでテストし、自分が正しかったと確信して、開発者にプル リクエストを送信しました。 念のため、プロジェクトリーダーは Petya がチェックしたかどうかを明らかにしてから追加しました。 しかし、開発サーバーへのデプロイメントは失敗しました。

実際、これは可能であり、誰もこれを免れることはできません。 これは、テーブル構造への変更が何らかの形でデータベースの特定のデータに関連付けられている場合に発生します。 明らかに、Petya のデータベースがテスト データのみで満たされている場合、すべての問題ケースをカバーできない可能性があります。 たとえば、テーブルを削除すると、削除されるテーブルのレコードに関連する外部キーによって他のテーブルのレコードが存在することがわかります。 または、列の型を変更する場合、データの 100% を新しい型に変換できないことがわかります。

決め方

• 移行とともに一度使用される特別なスクリプトを作成し、データを適切な形式にします。 これは、移行の適用後にデータを新しい構造に転送する問題を解決する一般的な方法ですが、特殊な場合には、同様の方法を以前に適用することもできます。 もちろん、ライブ サーバー上のデータの編集は危険であり、破壊的な場合さえあるため、このパスは常に利用できるわけではありません。
• もう XNUMX つの難しい方法は、既存の変更セットを編集することです。 問題は、既存の形式ですでに適用されているすべてのデータベースを復元する必要があることです。 バックエンド チーム全体がデータベースを最初からローカルに展開することを余儀なくされる可能性は十分にあります。
• そして最も普遍的な方法は、データに関する問題を開発者の環境に転送し、同じ状況を再現して、壊れた変更セットに新しい変更セットを追加することで問題を回避することです。
  

一般に、データベースの構成が実稼働サーバーのデータベースと類似しているほど、移行に関する問題が深刻になる可能性は低くなります。 そしてもちろん、変更セットをリポジトリに送信する前に、何かが壊れないかどうかを何度も考える必要があります。

状況 3. Liquibase は実稼働後に使用され始める

チーム リーダーが Petya に Liquibase をプロジェクトに含めるよう依頼したが、プロジェクトはすでに運用中であり、既存のデータベース構造が存在するとします。

したがって、問題は、新しいサーバーまたは開発者マシンでは、これらのテーブルを最初から再作成する必要があり、既存の環境は一貫した状態を維持して、新しい変更セットを受け入れる準備ができている必要があることです。

決め方

次のような方法もあります。

• XNUMX つ目の最も明白な方法は、新しい環境を初期化するときに手動で適用する必要がある別個のスクリプトを用意することです。
• XNUMX つ目は、それほど明確ではありませんが、別の Liquibase コンテキスト内に Liquibase 移行を作成し、それを適用します。 Liquibase Context について詳しくは、こちらをご覧ください。 https://www.liquibase.org/documentation/contexts.html。 一般に、これはテストなどにうまく使用できる興味深いメカニズムです。
• 2 番目のパスは、いくつかのステップで構成されます。 まず、既存のテーブルに対して移行を作成する必要があります。 次に、それを何らかの環境に適用する必要があり、そのハッシュサムが取得されます。 次のステップは、空ではないサーバー上で空の Liquibase テーブルを初期化することです。変更セットの使用履歴を含むテーブルに、データベースにすでに存在する変更を含む「適用されたような」変更セットに関するレコードを手動で配置できます。 。 したがって、既存のサーバーでは履歴のカウントダウンがバージョン XNUMX から始まり、すべての新しい環境は同じように動作します。
  

状況 4. 移行が大規模になり、完了する時間がない

サービス開発の開始時には、原則として Liquibase が外部依存関係として使用され、すべての移行はアプリケーションの開始時に処理されます。 ただし、時間が経つと、次のようなケースに遭遇する可能性があります。

• 移行は大規模になり、完了までに長い時間がかかります。
• 分散環境では、たとえば、複数のデータベース サーバー インスタンスを同時に移行する必要があります。
  この場合、移行を適用する時間が長すぎると、アプリケーションの起動時にタイムアウトが発生します。 さらに、移行を各アプリケーション インスタンスに個別に適用すると、異なるサーバーが同期しなくなる可能性があります。

決め方

このような場合、プロジェクトはすでに大規模であり、おそらく成人向けのプロジェクトでもあり、Liquibase は別個の外部ツールとして機能し始めます。 実際、Liquibase はライブラリとして jar ファイルにコンパイルされ、プロジェクト内の依存関係として、または独立して機能します。

スタンドアロン モードでは、移行の実装を CI/CD 環境に任せることも、システム管理者や導入スペシャリストの強力な責任に任せることもできます。 これを行うには、Liquibase コマンドラインが必要です。 https://www.liquibase.org/documentation/command_line.html。 このモードでは、必要な移行がすべて実行された後にアプリケーションを起動できるようになります。

出力

実際、データベースの移行を行う場合には、さらに多くの落とし穴が存在する可能性があり、その多くは創造的なアプローチを必要とします。 ツールを正しく使用すれば、これらの落とし穴のほとんどは回避できることを理解することが重要です。 具体的には、リストされているすべての問題にさまざまな形で対処する必要があり、その一部は私のミスによるものでした。 もちろん、これはほとんどが不注意によって発生しますが、場合によっては犯罪者がツールを使用できないことが原因で発生します。

出所： habr.com