1

.NET Migrations Engineのすべてのオプションを調べましたが、Railsスタイルの移行を使用するエンジンが最も興味深いことがわかりました。これは主に、データベースに依存しない方法で記述されており、別のデータベースに対して簡単に使用できるためです。プラットホーム。

しかし、私はそれらのどれもすぐに解決できないように見える1つの明白な問題を見ました：ソース管理の分岐。

シナリオ

  1. 機能1はbranch1で開発されており、column1という名前のテーブルに列を追加します。
  2. 機能2はbranch2で開発されており、column2という名前の同じテーブルに列を追加します
  3. 機能2を含むリリース1.1が作成されていますが、機能1はまだ完成していません
  4. 機能1が完了し、トランクにマージされます
  5. リリース1.2が作成されましたが、トランクに入った新しいcolumn1フィールドはバージョン1（コードで直接リリース1.1に関連付けられている）であったため、移行時にデータベースで更新されません。

Migrator.NETなどのツールでは、問題は、移行バージョンがSCCコミットではなく、実際のソフトウェアリリースに関連していることであるように思われます。ただし、属性はソース管理のコードに追加する必要があります。バージョンの代わりに日付が使用された例を見たことがありますが、それはインクリメンタルバージョン管理以上に目前の問題を解決していないようです。

私が見つけた答えに最も近いのはLiquibaseFAQページでしたが、.NETのRailsスタイルのフレームワークの場合（liquibase変更ログファイルと同様の属性を構造化するRik Migrationsでも）、ソリューションではコードを変更する必要があります。 ：

Liquibaseはブランチで動作しますか？ はい。それぞれの変更は独立しているため、異なるブランチで行われ、次にマージされたデータベースの変更は、次にLiquibaseが実行されるときに実行されます。ステートメントが実行される順序で問題が発生する可能性がありますが、変更ログファイルを並べ替えることで、問題を簡単に解決できます。

この問題を処理する一般的な方法は何ですか？

違いが生じる場合は、ソース管理にGitを使用しています。複雑な分岐システムでのデータベースの移行というタイトルの投稿はすでに見ましたが、実際には答えが得られなかったことに注意してください。

4

1 に答える 1

1

私はこれにいくつかの考えを与えました、そしてこれは私がこれまでに思いついたものです。移行フレームワークはまだ決めていませんが、以下の方法は、属性を使用するMigrator.NETのようなものを想定しています。ただし、これは他の移民にも適用できます。

問題は、移行が時期尚早に（リリース中ではなく開発中に）バージョン管理されるという事実にあるため、私の最初の本能は、リリースまで移行をバージョン管理できないようにするワークフローを考え出すことです。これは、ビルドスクリプト、単体テスト、およびソース管理を使用して実行できます。手順は次のとおりです。

  1. CIプロセス中に実行される現在のデータベースバージョンよりも高いバージョンでMigrationAttributesが存在する場合に失敗する単体テストを作成します
  2. CIプロセス中に実行される現在のデータベースバージョン以下の移行に変更が加えられたときに失敗する単体テストを作成します
  3. CIビルドの前に、Migrationクラスから継承するすべてのクラスを検索するステップを追加し、現在のデータベースバージョンよりもバージョン1高いMigrationAttributeを追加します。これにより、CIプロセスで移行が正常に実行されるようになります。このステップの前に、ステップ1と2の単体テストが実行されていることを確認してください。
  4. CIビルドの後にステップを追加して、データベーステーブルの現在のデータベースバージョンを現在リリースされているデータベースバージョンに戻します。CIプロセスデータベースのバージョン管理は一時的なものです。
  5. Migrationクラスから継承するすべてのクラスを見つけるリリースビルドの前にステップを追加し、現在のデータベースバージョンよりもバージョン1高いMigrationAttributeを追加します。このコード変更をトランクにコミットします。

ここでの一般的な前提は、これらすべてを完全に自動化でき、データベース移行バージョン属性が一時的なCIビルドステップとリリースステップの両方として（手動ではなくビルドプロセスによって）追加されることです。単体テストでは、移行の編集や開発サイクルの早い段階でのバージョン管理に関して不正行為が行われないことを確認します。

もちろん、ステップ3と4は、CIプロセスでドロップ/再作成の方法論に置き換えることができ、おそらくより信頼性が高くなります。重要なのは、データベースのバージョン管理が行われ、リリース中にソース管理にチェックインされることです（以前はチェックされませんでした）。

バージョニング

このワークフローに対応するために、データベースバージョンをAssemblyInformationalVersion属性の一部にすることを検討しています。

[assembly: AssemblyVersion("1.2.0.0")]
[assembly: AssemblyFileVersion("1.2.3.4")]
[assembly: AssemblyInformationalVersion("1.2.3.4+<GitHash>-<DBVersion>")]

したがって、上記の例では、データベースのバージョンがアセンブリの後に挿入されます。これにより、通常のメジャー/マイナー+ビルドバージョンを使用できるようになりますが、アセンブリ内の現在のビルドのデータベースリリースバージョン（およびGitのヘッドコミット）を追跡することもできます。その後、リリースプロセスはそれに応じてこのバージョンをインクリメントし、すべての単体テストとその他の手順が続きます。AssemblyInvormationalVersionは、Windowsでは製品バージョンとして表示されることに注意してください。

GitHashは最初の7文字のみであり、とにかくそれを一意にするのに一般的に十分です。

概要

これから取り除く主なことは、ソースコードにはどのブランチにもデータベースのバージョン管理属性が含まれていないため、データベースのリリースに干渉することなく、分岐が必要なだけ複雑になる可能性があることです（含まれている場合、ビルドは失敗します） 。ただし、ブランチにはデータベースの移行に必要な情報が含まれます。これは実際には開発ステップであり、リリースステップではありません。

明らかに、単体テストとビルドスクリプトには、リフレクション、コードインジェクション、およびソース管理プロバイダーと協力してルールが守られていることを確認する必要がありますが、それはすべて確実に可能です。

私はこれを実際にテストしていませんが、別の解決策が見つからない場合は、おそらくこれが私が進む方向です。

于 2012-08-27T17:25:05.337 に答える