11

データベース スキーマをアップグレードする必要があると、新しいリリースのソフトウェアをインストールするのが非常に面倒になります。これを行うためのベストプラクティスは何ですか?

次のようなアクション アイテムのチェックリストまたはタイムラインを探しています。

  • 8:30 アプリをシャットダウン
  • 8:45 スキーマの変更
  • 9:15 新しいアプリをインストール
  • 9:30 データベース再起動

など、リスクとダウンタイムを最小限に抑える方法を示します。などの問題

  • うまくいかない場合はアップグレードを取り消す
  • 既存のアプリへの影響を最小限に抑える
  • データベース実行中の「ホット」更新
  • 開発からテスト、本番サーバーへの昇格

は特に興味があります。

4

5 に答える 5

5

私はこれについて多くの経験を持っています。私のアプリケーションは反復性が高く、スキーマの変更が頻繁に発生します。私はおよそ 2 週間から 3 週間ごとに製品版のリリースを行っており、それぞれの項目について、FogBugz リストから 50 から 100 の項目をクリアしています。過去数年間に行ったすべてのリリースでは、新機能をサポートするためにスキーマの変更が必要でした。

これの鍵は、ライブサーバーで実際に変更を行う前に、テスト環境で変更を数回練習することです。

私は、テンプレートからコピーされたデプロイ チェックリスト ファイルを保持しており、リリースごとに通常とは異なる部分を大幅に編集しています。

データベースで実行するスクリプトは 2 つあります。1 つはスキーマの変更用、もう 1 つはプログラミング (プロシージャ、ビューなど) 用です。変更スクリプトは手作業でコーディングされており、procs を含むスクリプトは Powershell を介してスクリプト化されています。変更スクリプトは、すべてがオフになったときに実行され (これを実行するユーザーの数が最も少ない時間を選択する必要があります)、異常が発生した場合に備えて、コマンドごとに手動で実行されます。私が遭遇した最も一般的な問題は、重複行のために失敗する一意の制約を追加することです。

統合テスト サイクルの準備をするときは、テスト サーバーでチェックリストを調べます。そのサーバーが運用環境であるかのように。次に、それに加えて、実稼働データベースの実際のコピーを取得し (これは、オフサイト バックアップを交換する良い機会です)、復元されたローカル バージョンでスクリプトを実行します (これも、私の最新のバックアップは健全です）。ここでは一石二鳥です。

つまり、合計 4 つのデータベースです。

  1. 開発者: すべての変更は変更スクリプトで行う必要があり、Studio を使用することはありません。
  2. テスト: 統合テストはここで行われます
  3. 実動のコピー: 最後の展開の練習
  4. 製造

本番環境で行うときは、本当に、本当に正しく行う必要があります。スキーマの変更を取り消すのは困難です。

ホットフィックスに関しては、非常に孤立した変更であり、ビジネスにとって重要でない限り、ホットフィックス手順のみを行い、スキーマは決して行いません。

于 2008-08-28T01:39:40.673 に答える
2

スコット・アンブラーの読み物を検討したと思いますか? http://www.agiledata.org/essays/databaseRefactoring.html

于 2008-08-27T21:15:14.257 に答える
1

また、Scott Ambler の論文が食欲をそそる場合は、Pramod J Sadolage と共著の「Refactoring Databases」という彼の本をお勧めします - http://www.ambysoft.com/books/refactoringDatabases.html

Yahoo の Agile Database グループ ( http://tech.groups.yahoo.com/group/agileDatabases/ ) にも、役立つアドバイスや情報がたくさんあります。

于 2008-08-28T02:43:33.780 に答える
1

2 つの簡単なメモ:

  1. 言うまでもありませんが…二度言います。
    有効なバックアップがあることを確認します。
    有効なバックアップがあることを確認します。

  2. @mk. データベースのバージョン管理に関するJeff のブログ投稿をチェックしてください(まだお持ちでない場合)。

于 2008-08-28T04:44:58.077 に答える
1

これは私が職場で話していた話題です。主な問題は、データベースの移行がフレームワーク (レールとその移行スクリプトなど) によって適切に処理されない限り、それはあなたに任されていることです。

私たちの現在のやり方には明らかな欠陥があり、私は他の提案を受け入れます.

  1. 最新の状態に保ち、バージョン管理する必要がある静的データを含むスキーマ ダンプを用意します。
  2. スキーマ変更アクションを実行するたびに、ALTER、CREATE などでそれをファイルにダンプし、バージョン管理にスローします。
  3. 元の sql db ダンプを必ず更新してください。
  4. ライブへのプッシュを行うときは、あなたまたはあなたのスクリプトがSQLファイルをデータベースに適用していることを確認してください。
  5. バージョン管理されている古い sql ファイルは、古くなったときにクリーンアップします。

これは決して最適ではなく、「バックアップ」データベースとして意図されたものではありません。それは単に、ライブへのプッシュを容易にし、開発者を同じページに保つためです. データベースへのSQLファイルの適用を自動化する限り、おそらくカピストラーノでセットアップできるクールなものがあります。

データベース固有のバージョン管理は非常に素晴らしいものです。おそらくそれを行う何かがあり、ない場合はおそらくあるはずです。

于 2008-08-28T01:29:11.930 に答える