機能ブランチを操作するときにFlywayを使用する方法
最近、作業するストーリーごとに機能ブランチを使用するようになりました。これらは可能な限り独立しており、プロジェクトマネージャーがリリースを構成するストーリーを決定します。これは、ストーリーが最初に制作される正確な順序を知っていることを意味します。
Flywayでこれに対処する標準的な方法はありますか？ FAQは、本番データベースへの変更がどのように線形になるかについて説明していますが、これは正しいです。しかし、チームメンバーがどのバージョン番号を移行に与えるかを決定する方法がわかりません。彼らは機能ブランチに取り組んでいます。また、リリース前に統合ブランチとマスターにマージするときに、移行ファイルの名前を手動で変更する必要があります。
OutOfOrderを有効にし、バージョン番号としてタイムスタンプを使用するために、ブランチ間のバージョン管理の問題を克服するために私が見た最良の方法
デフォルトでは、ほとんどの移行フレームワークは、以下の例のように、個々の移行の前に整数を付けることを選択します。フレームワークは、現在のデータベースにまだ適用されていない移行を検出すると、プレフィックスがデータベースに存在しない最初の移行から開始し、昇順で適用を開始します。
- 1.0.0.1__add_customers_table.sql
- 1.0.0.2__add_email_address_column_to_customers_table.sql
- 1.0.0.3__add_orders_table_with_reference_to_customer_table.sql
これは、全員が同じコードブランチにいる場合にうまく機能します。ただし、チームのメンバーが自分のブランチで作業を開始すると、プレフィックスの衝突の可能性が劇的に高まります。
ただし、整数ではなくタイムスタンプを使用して移行のプレフィックスを付けることを選択した場合、ブランチ間でも衝突の可能性は事実上なくなります。たとえば、yyyyMMddHHmmssSSSなどのパターンを使用すると、上記の移行は次のようになります…
- 1.0.0.20130704144750766__add_customers_table.sql
- 1.0.0.20130706132142244__add_email_address_column_to_customers_table.sql
- 1.0.0.20130706151409978__add_orders_table_with_reference_to_customer_table.sql
上記のタイムスタンプパターンは、ミリ秒まで正確です。タイムスタンプが非常に正確であるとプレフィックスが読みにくくなる可能性がありますが、プレフィックスが正確であればあるほど、衝突が発生する可能性は低くなります。
最良の結果を得るには、このタイムスタンプの作成を自動化して、チームのすべてのメンバーが一貫した形式を使用できるようにする必要があります。
さらに、Flywayはタイムスタンププレフィックスも整数として扱うことに注意してください。つまり、最初に整数を使用してFlywayで作業を開始した場合でも、いつでもタイムスタンプに切り替えることができます。タイムスタンプは非常に大きな整数であるため、最初のタイムスタンププレフィックス付き移行は、最後の整数プレフィックス付き移行の後に適用されます。
ここから取得し、わずかに変更しました： http://www.jeremyjarrell.com/using-flyway-db-with-distributed-version-control/
バージョンとしてタイムスタンプを使用することは良い考えのようです。私が目にする唯一の問題は、チームが世界中に分散している場合です。その場合、標準として1つのタイムゾーンを選択する必要があります。