私たちは外部の有料クライアント向けの製品を開発しており (つまり、私たちは管理範囲内の環境向けの製品のみを生産する内部 IT 部門ではありません)、現在、バックエンドとして SQL Server 2005+ と Oracle 10.2+ の両方をサポートする必要があります。私たちは CI とビルドのために Wix で TeamCity を使用します。ビルドはテスト チームに送信され、最終的にはテストが承認されたときにクライアントに送信されます。現在、データベースをアップグレードするための SQL スクリプトは無数にあります。最も基本的な形式では、DDL スクリプトとデータ スクリプト (バージョンごと、プラットフォームごと) が存在する場合がありますが、ストアド プロシージャを含むスクリプトやクライアント固有のスクリプトが存在する場合もあります。クライアントがアップグレードするバージョンの数 (たとえば、2.0 から 2.7) によっては、20 ものスクリプトを正しい順序で実行する必要がある場合があります。
明らかに人的ミスの余地があり、現在ダウングレードする方法はありません。スクリプトの自動バージョン番号付けの欠陥のおかげです (そして、DB がどのスクリプトが実行されたかを記録しているかなりばかげた方法です)、そうではありません。 DB で実行されたものを常にクリアします。明らかに、これは素晴らしい状況ではありません。
私はFluent Migratorまたは同様のものの使用を調査しています-Fluentである必要はありません-プロセス全体にもう少し順序とバージョン管理を導入しようとしていますが、使用方法に関する記事や例はたくさんありますCI では、移行を MSI インストーラーなどに統合することについては何も見つかりません。
私がやりたいのは、全体的なインストーラーの一部としてそれを使用するか、データベースのアップグレード/ダウングレード専用のインストーラーを作成することです。クライアント固有の移行はさておき、このようなインストーラーからユニバーサル移行を実行することは可能ですか? もしそうなら、1 つのインストーラーで複数のプラットフォームを対象にする (つまり、SQL と Oracle の両方の移行を利用可能にし、実行時にどちらを使用するかを検討する) ことはどうでしょうか?
私の計画は、移行を単一のアセンブリに保持し (この記事の説明と同様)、インストーラーが作成されたときに焼き付けられた情報に基づいて、適切なアップ/ダウン マイグレーションをインストーラーに実行させることです。それができると仮定すると、これは賢明な解決策のように聞こえますか、それとも私が気付いていないこれらすべてを管理するより良い方法はありますか?
どうもありがとう
スティーブ