データベースの初期スキーマを作成する移行ファイルと、初期スキーマにランダム データとセット タイプを設定するシード ファイルがあります。
移行とシードについての私の理解では、新しいチームメンバーが参加するたびに、それらを実行するだけで、すべてのデータベースの変更と製品が機能するために必要なデータに追いつくことができます。さらに、stg とシードに変更を適用できます。移行ファイルを実行して prod を実行します。
しかし、私のプロジェクトが進むにつれて、新しいタイプのデータが出現し、それらを適用する唯一の方法は、データベースへの挿入を実行する移行を作成することでした。
私が抱えている問題は、職人が移行とシードを処理する方法は、最初にすべての移行を実行し、次にすべてのシードを実行することであり、移行の順序を指定する方法がないように思われることです。実行する必要があります。したがって、migrate:refresh --seedを実行すると、シードが自身のデータを挿入する前に新しいデータを挿入する最新の移行が適用されるため、エラーが発生します (シードに挿入されたタイプに依存する場合とそうでない場合があります)。 .
私たちが試みた 1 つの解決策は、シードも更新し、データを挿入する移行で変更を適用する前に確認することですが、これは維持するのが非常に面倒になりました。
このシナリオでの移行とシードの予想される用途は何ですか?
更新 より明確にするために: ユーザーを作成するための移行があるとしましょう: ユーザー:{id, name, type} そして、ユーザーを作成するためのシードがあります。
私は両方を実行し、多数のユーザーを含む users テーブルを持っています。
時間が経ち、user_types 用のテーブルが必要であると判断しました。移行が作成され、新しいテーブルが作成され、新しいユーザー タイプのデータが取り込まれ、現在の user.type が user.type_id に一致するように更新されます。
開発者は移行を実行し、データベースをすべて最新の状態にしています。
新しい開発者がチームに加わります。彼は移行を実行します。それから種。壊れます。
ここで、シードを更新して最新のものに一致させると、user_types テーブルの重複データに遭遇します。これを回避するには、データがない場合は実行しないように、移行に何らかの防御コードを用意し、データがある場合は更新する必要があります。
問題は、これが移行を使用する正しい方法ですか? シードを再実行することなく、データの変更をすべての開発者にプッシュするにはどうすればよいでしょうか?