データベース変更の展開をどのように処理しますか？

今日、データベースデプロイメントテクニックについて議論しており、現在のプロセスでいくつかの最近の失敗があり、デプロイメントをロールバックしたいが、アプリケーションの古いバージョンが新しいバージョンに対してテストされたことがない状況を見てきましたデータベース。

一方では、バージョンアップ命令とバージョンダウン命令（SQLまたはアプリケーション言語で書かれているかどうか）があり、アプリは到達する必要のあるバージョンを知っている移行スタイルのデプロイメントがあります。

これらは単純であり、あまりロールバックしないため、開発者は単純に熱心です。ただし、フィールド/テーブルを追加していて、ロールバックする前にそのフィールドにデータが入力されると、リスクがあります。さらに悪いことに、以前のバージョンに関連するデータをドロップした場合。

一方、アップグレード、ロールバック、ロールフォワードのアプローチを検討することもできます。このアプローチでは、ロールバックが移行ほど劇的ではありません。たとえば、アップグレードにより、null不可フィールドが追加される場合があります。rollbackはnullを許可するので、古いアプリは気にしません。rollforwardは、nullフィールドにデータを入力し、再びnull不可にします。

これはデータを保持しますが、コーディングとテストの両方が複雑です（残念ながら、自動化された統合テストはほとんど存在せず、修正中に問題が発生します）。

これらの問題を軽減する安全な方法はありますか？他に検討すべきオプションはありますか？後で痛みを和らげることができる悪い経験を共有したいですか？

データベースの変更は、他のすべての変更と同様に処理し、展開の一部としてスクリプトとして展開する必要があります（もちろんソース管理に保存します）。同じバージョンのアプリケーションのコードを使用してデプロイされるため、ロールバックする必要があるものを正確に把握できます。データベーススクリプトの作成時に、各変更を元に戻すための空想を作成し、スクリプトを作成できますが、ロールバックが一般的でない場合は、それを実行したくない場合があります。新しい列にデータが入力されると、元のデータベースに戻るとデータが失われます。

SQL Serverでは、展開の直前にスナップショットを作成し、展開が失敗した場合にすぐにスナップショットに戻ることができます。これは、ユーザーがシステム上にいるときに展開が行われないことを前提としています（データの変更を失いたくない）。これは、メジャーリリース中に、システム全体を一時的にアップグレードしてアップグレードする必要がある場合に最も役立ちます。または、スナップショットを取得し、スナップショットとデータベースをデータベースで比較して、ロールバックする必要がある場合に違いを確認できます。SQLCompareのようなツールは、スナップショット構造に戻るためのコードを生成することもできます。他のデータベースで利用できるものがわかりません。

データベース構造の変更は、テスト環境を使用して自動化/スクリプト化し、テストする必要があります。本番環境での手動の変更はリスクが大きすぎる

唯一の合理的なロールバック戦略（事態を悪化させる可能性が最も低い戦略）は、アップグレード前のスナップショットに戻ることです。物事がうまくいかない場合は、スナップショットに戻るのに十分な速さで発生するか、ロールバックするには遅すぎます（次の週のレポートはデータベースの問題のため失敗します）。

変更は段階的に（フィールドの追加など）実行できるため、1回のパスですべてを実行する場合よりもリスクを抑えてライブでテストできます。

計画を立てることで、各リリースでソフトウェアとデータベースのアップグレードに立ち向かう代わりに、データベースに変更を加えて、今後のいくつかのリリースをサポートできます。

ソフトウェアのアップグレードの場合と同じように、データベースのアップグレードの翌日に緊急モードになる準備をします。

問題を手動で修正する衝動に抵抗します。緊急時の戦略（ロールバック、スナップショット）を使用し、アップグレードを再試行する前に、問題が発生した理由を考えてください。