最近、私たちが取り組んでいる各ストーリーにフィーチャー ブランチを使用するようになりました。これらは可能な限り独立しており、プロジェクト マネージャーがリリースを構成するストーリーを決定します。これは、ストーリーが最初に制作される正確な順序がわからないことを意味します。
Flyway でこれを処理する標準的な方法はありますか? 本番データベースへの変更がどのように線形になるかについて説明している FAQ を読みましたが、これは正しいです。ただし、チーム メンバーが機能ブランチで作業しているときに、移行に与えるバージョン番号をどのように決定するかはわかりません。また、リリース前に統合ブランチとマスターにマージするときに、移行ファイルの名前を手動で変更する必要があります。
ブランチ間のバージョン管理の問題を克服して outOfOrder を有効にし、タイムスタンプをバージョン番号として使用するために私が見た最良の方法
デフォルトでは、ほとんどの移行フレームワークは、以下の例のように、個々の移行の前に整数を付けることを選択します。フレームワークは、現在のデータベースにまだ適用されていない移行を検出すると、プレフィックスがデータベースに存在しない最初の移行から開始し、昇順で適用を開始します。
これは、全員が同じコード ブランチにいる場合にうまく機能します。ただし、チームのメンバーが独自のブランチで作業を開始すると、プレフィックスの衝突の可能性が劇的に増加します。
ただし、整数ではなくタイムスタンプを使用して移行のプレフィックスを付けることを選択した場合、ブランチ間であっても衝突の可能性は事実上なくなります。たとえば、yyyyMMddHHmmssSSSなどのパターンを使用すると、上記の移行は次のようになります...</p>
上記のタイムスタンプ パターンは、ミリ秒まで正確です。タイムスタンプが非常に正確であると、プレフィックスが読みにくくなる可能性がありますが、プレフィックスが正確であるほど、衝突の可能性は低くなります。
最良の結果を得るには、このタイムスタンプの作成を自動化して、チームのすべてのメンバーが一貫した形式を使用するようにします。
さらに、Flyway はタイムスタンプのプレフィックスも整数として扱うことに注意してください。これは、最初に整数を使用して Flyway で作業を開始した場合でも、いつでもタイムスタンプに切り替えることができることを意味します。タイムスタンプは非常に大きな整数であるため、最初のタイムスタンププレフィックス付きの移行は、最後の整数プレフィックス付きの移行の後に単純に適用されます。
ここから取得し、わずかに変更: http://www.jeremyjarrell.com/using-flyway-db-with-distributed-version-control/
取得するものと同じバージョン番号の移行スクリプトを使用することはできません。
バージョン 'xyz' で複数の移行が見つかりました (犯罪者: SQL ...)
私が提案する回避策は次のとおりです。複数の開発者が同じバージョン、たとえば1.0異なる機能で作業しています。のように、各課題に ID を追加する課題トラッカーを使用していると思いますFOO-16。開発者がその問題に取り組むとき、移行スクリプトは と呼ばれV1.0.16__my_greatest_feature.sqlます。このように (各機能/ブランチに独自の問題があると仮定して) 衝突はありません。
また、データベース移行スクリプトは独立しており、重複していないと想定していますが、そうでない場合は、すべてを安定版リリースにマージする際に問題が発生します。
したがって、安定版リリースでは、いくつかの移行スクリプトV1.0.16にギャップがV1.0.27あります。安定版リリースにならなかったすべての機能(例: ) は、次のメジャー リリースを対象とするように名前を変更する必要があります (例: )。V1.0.101FOO-16FOO-27FOO-1011.0V1.0.35V1.1.35