私の目標の 1 つは、古いバージョンと並行して実行される Web アプリケーションの新しいバージョンをデプロイできるようにすることです。問題は、すべてがデータベースを共有することです。新しいバージョンのデータベースには、データベース テーブルへの大幅なリファクタリングが含まれる傾向があります。アプリケーションの新しいバージョンを徐々にユーザーにロールアウトし、必要に応じてユーザーを古いバージョンに戻せるようにしたいと考えています。
Oren は問題を設定する良い投稿をしましたが、次のように終わりました。
「システム全体に影響を与える変更、つまり、データベースの変更を破壊することに関して、本番環境へのデプロイに関しては、まだやや混乱しています。次の記事で、これは少しだけ出てきたことについて説明します。手、恐れ入ります。」
後続の投稿は来ませんでした;-)。同じアプリケーションの古いバージョンで共有されているデータベースへの重大なデータベース変更の移行をどのように管理しますか? データの同期をどのように維持しますか?
Scott Ambler の著書 " Refactoring Databases " を読んでください。塩のピンチを取るが、そこにはかなり多くの良いアイデアがあります.
利用可能なソリューションの詳細は、使用する DBMS によって異なります。ただし、次のようなことができます。
状況によっては、新しいテーブルは必要なく、トリガーだけが必要な場合があります。
古いバージョンを維持する必要がある場合、変更が壊れることはありません。これは、Web アプリの新しいバージョンをデプロイするときにも役立ちます。ロールバックする必要がある場合は、データベースをそのままにしておくことができれば非常に役立ちます。
明らかに、これには重大なアーキテクチャ上のハンディキャップが伴い、ほぼ確実に、いわばその系統を示すデータベースになりますが、私の経験では、展開の利点は通常、頭痛の種に値します。
関連する古いバージョンごとに統合テストのしっかりしたコレクションがあると役立ちます。まだ「おそらくライブ」であると見なされているすべてのバージョン（場合によっては「これまでのすべてのバージョン」である可能性があります）について、移行されたテストデータベースに対してそれらを実行できるはずです。展開を合理的に厳密に制御できる場合は、3 つまたは 4 つのバージョンの互換性のみで済む可能性があります。その場合、本当に必要な場合は、廃止されたテーブル/列などを段階的に廃止することを計画できます。発生した利益に対するそのような計画の複雑さを心に留めておいてください.
クライアントのバージョンが 2 つだけだとすると、新しいテーブルにはデータのコピーを 1 つだけ保持します。
新しいテーブルの上にあるビューの背後にある古いアプリと新しいアプリの間の契約を維持できます。トリガーの前/代わりに使用して、実際に新しいテーブルに書き込む「古い」ビューへの書き込みを処理します。
2 つのバージョンのコードを維持しており、古いアプリを引き続き開発する必要がありますが、それは避けられません。
このように、同期の問題はありません。事実上、「古い」スキーマと「新しい」スキーマ間のレプリケーションの競合に対処する必要があります。
前述のように、2 つ以上のバージョンは複雑になります...
まず、この問題は非常に難しく、完全な答えが見つからない可能性があることをお伝えしたいと思います。
最近、私はレガシー基幹業務アプリケーションの保守に携わっていますが、これはまもなく新しいバージョンに進化する可能性があります。メンテナンスには、バグの解決、古いコードの最適化、および新しい機能が含まれますが、これらは現在のアプリケーション アーキテクチャに簡単に収まらない場合があります。私たちのアプリケーションの主な問題は、文書化が不十分であり、変更の痕跡がなく、基本的にこのプロジェクトに取り組んでいる 5 番目のローテーション チームです (私たちはかなり新しいプロジェクトです)。
外部の詳細 (コード、レイヤーなど) は脇に置いて、現在データベースの変更をどのように管理しているかを少し説明します。
現時点では、従おうとしている 2 つのルールがあります。
第一に、古いコード (SQL、ストアド プロシージャ、関数など) はそのまま機能し、場合 (バグや機能の変更) がない限り、あまり変更せずにそのまま保持する必要があります。もちろん、それを文書化するようにしてください。可能な限り（特に、「なんてこった！、なぜ彼はそれの代わりにそれをしたのですか？」のような問題）。
2 つ目は、登場するすべての新機能は、現時点で知られているベスト プラクティスを使用し、古いデータベース構造をできるだけ変更しないようにすることです。これにより、古い構造の上に編集可能なビューを使用したり、既存のテーブルに新しい拡張テーブルを導入したり、構造を正規化したり、ビューを介して古い構造を提供したりするなど、いくつかのデータベース リファクタリング オプションが導入されます。
また、ビジネス アナリストが並んで作業し、ビジネス ルールを文書化しているという条件で、できるだけ多くの単体テストを記述しようとしています。
データベースのリファクタリングは非常に複雑な分野であり、簡単に答える必要があります。すべての問題に答える本がたくさんあります.1つは http://databaserefactoring.com/が答えの1つに示されています.
後で編集: うまくいけば、2 番目のルールも重大な変更の処理に対応します。