はじめに
プロジェクトに複数の開発者が携わっている場合、開発データベースの変更に追従することは困難な場合があります。これらの変更を開発チーム全体で同期させる作業は、面倒で時間がかかります。様々なチームメンバーがデータベースのスキーマや、最新の状態を反映していない開発データベースのデータで作業する場合、それはフラストレーションを引き起こし、最終的に本番環境でバグにつながる可能性があります。
特に、以下のシナリオでこれらの問題が発生する可能性があります
- 開発者がデータベーススキーマの異なるイテレーションで作業している
- 開発データベースのデータがスキーマの現在の状態を反映していない
このガイドでは、チームがデータベーススキーマと開発データをチーム間で最新かつ同期した状態に保ついくつかの方法について見ていきます。
オンボーディング中に開発データベースをセットアップする
データベーススキーマと開発データへの変更がチームメンバー間で共有される前に、それらのチームメンバーは初期のデータベース状態を用いてブートストラップされる必要があります。ほとんどのチームでは、これはプロジェクトでの作業を開始する際のオンボーディングプロセスの一部です。このプロセスの洗練度は、組織の規模と成熟度、およびそのニーズに大きく依存します。
ほとんどのオンボーディング中の開発者にとっての出発点は、プロジェクトをローカルにクローンしてインストールすることです。次に、通常は開発データベースに接続する必要があります。新しい開発者が開発データベースをセットアップする最も一般的な2つの方法は、次のとおりです。
- ローカル開発データベースをシードするためのスクリプトを実行する
- 共有リモート開発データベースに接続する
これらのアプローチはどちらも、それぞれに利点と欠点があります。
ローカルデータベースのシード
ローカルデータベースをシードすることは、リモート開発データベースを実行する必要性を軽減するため有益です。開発者は、作業を開始する際に、開発データベースに入れるデータをより細かく制御できます。また、共有リモートデータベースを使用する場合よりも、データベースを簡単にリセットできます。
このアプローチを採用する場合、シードデータとロジックを現在のスキーマと同期させるために、追加の労力が必要です。変更が頻繁に発生する場合、これは課題となり、開発者のスムーズなオンボーディングを妨げる可能性があります。
Prisma Clientを使用している場合、統合されたシード機能を使用して、データベースを簡単に投入できます。
共有リモートデータベースへの接続
開発者が共有リモート開発データベースに接続することで、新規開発者のデータベースをローカルで投入する負担を軽減できます。これは、初期のオンボーディングを容易にし、開発者がより早く生産的になることを可能にするため、役立ちます。共有リモートデータベースを使用することは、データベースへの変更が単一の開発者によって定期的にマイグレーションされ、それらの変更がすべてのチームメンバーによって利用されるため、有益である場合もあります。
共有リモート開発データベースを使用する欠点は、追加のリソースを実行する必要があり、追加のコストが発生する可能性があることです。さらに、すべての開発者が同じデータベースに対して作業している場合、データを上書きしやすくなります。もう一つの潜在的な問題は、スキーマの変更がチームメンバーによって非同期的に採用された場合、帯域外の変更がデータの状態に悪影響を及ぼし、作業を困難にする可能性があることです。
継続的なデータベース更新
ローカルであれリモートであれ、開発者が作業対象のデータベースをセットアップしたら、データベーススキーマの更新、場合によってはデータベース自体のデータの更新を継続的にチェックする必要があります。チームの規模が大きく、変更が頻繁に行われる場合、これは困難になる可能性があります。
スキーマ変更をチームメンバー間で最新の状態に保つための万能なアプローチはありません。あなたのチームにとって最適なアプローチは、状況によって異なります。
次のリストには、チーム間でデータとスキーマの変更を同期させるための全体的な戦略を構築するために組み合わせることができるいくつかのアプローチが含まれています。
マイグレーションの使用
チーム設定でリレーショナルデータベースを扱う場合、データベーススキーマ変更戦略の出発点としてマイグレーションを使用することが不可欠です。
データベースマイグレーションは、自動化を通じてデータベースの構造を変更できる一連の成果物です。最も単純な形では、マイグレーションとは、スキーマ変更を適用するために必要なステートメントを含むSQLファイルです。例えば、データベースモデルにフィールドを追加すると、次のSQLファイルが生成される可能性があります。
このコマンドは、ローカル開発環境のコンテキスト内で単一の開発者によって単独で実行できますが、データベースマイグレーションファイルとして存在させることで、チームの他のすべての開発者が自動化を通じて全く同じ変更を適用できるようになります。
特定のデータベースマイグレーション戦略は、言語やフレームワークによって異なります。しかし、一般的には同様のパターンに従います。
- データベースモデルを記述するコードを変更する
- マイグレーションファイルのセットを生成する
- マイグレーションを実行してステートメントを実行し、変更を適用する
Prisma Migrateは、データベースモデルを記述し、それらからマイグレーションを生成することを容易にします。これにより、チームメンバー間でデータを同期させる非常にシンプルな方法が提供されます。
チームメンバーに変更を通知する
変更戦略としてデータベースマイグレーションを使用することは、データベース構造の変更をチームメンバー間で同期させるのに役立ちます。しかし、それらの変更を開発者に通知することは困難な場合があります。
これは、2人以上のチームメンバーがデータベーススキーマの同じ部分、またはスキーマの特定の箇所を利用するアプリケーションの一部で作業している場合に問題となります。このようなシナリオは、マージの競合を引き起こし、フラストレーションの原因となる可能性が高いです。
この状況はチームのコミュニケーションを改善することで最もよく対処されますが、テクノロジーもある程度役立つことができます。
Gitフックを使用すると、さまざまなタイミングでスキーマの変更を開発者に通知できます。たとえば、開発者が変更をプッシュする前に、すでにマージされアップストリームに適用されているスキーマ変更をチェックするためにフックを使用できます。これにより、マージの競合を軽減し、チームの同期をより密に保つことができます。
この動作は、git-migration-hookを起点として、スクリプト化し、チームの特定のシナリオに適用できます。
データ同期の自動化
データベーススキーマが変更された場合、チーム全体が新しいスキーマに準拠するようにデータベースを再シードする必要がある可能性が高いです。シードスクリプトを維持し、配布し、チームの全員に継続的に適用させるのは面倒な作業です。
このプロセスを自動化する一つの選択肢は、データベース間で双方向のデータ同期を提供するサービスを利用することです。このようなサービスは、通常、さまざまな目的でリモートの本番データベースを同期するために使用されますが、チーム間で開発データを同期するためにも使用できます。そうすることで、チームは継続的に更新される独自のローカルまたはリモート開発データベースを使用できるようになります。そのようなサービスの一例は、Azure向けSQLデータ同期です。
まとめ
開発データベースの変更をチームメンバー間で同期し続けることは、困難な作業となりえます。チームが迅速に動き、同じスキーマで共同作業を行う場合、衝突の機会は非常に多くなります。
Gitフックやその他のツールを用いたワークフローを導入して自動化を提供することで、チームはスキーマ変更とデータをより簡単に同期させることができます。
