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