html / jsコードとアセットの更新（Subversionを使用）に関する限り、クライアントのWebサイトをアップグレードするための優れたプロセスがあり、非常に満足しています。
ただし、データベースのアップグレードに関しては、正式なプロセスはありません。
開発データベースに新しいテーブル/フィールドを追加する場合、それを本番サーバーにロールアウトする場合は、変更を記憶して複製する必要があります。クライアントデータ（ブログ投稿、アカウント情報など）が失われるため、開発データベースを本番データベースの上に単純にコピーすることはできません。
現在、同じ問題に遭遇するWebアプリを構築中です。
このプロセスを簡単にし、エラーが発生しにくいソリューションを誰かが持っていますか？大きなウェブアプリはどのようにして問題を回避しますか？
ありがとう。
開発プロセスにコントロールを追加することが最も重要だと思います。私の過去の仕事の 1 つで、すべてのデータベースの変更をスクリプト化する必要がありました。これらのスクリプトは、その後、どの環境にデプロイするかについての指示とともに DBA に渡されました。1 日の終わりには、技術的なソリューションを実装できますが、プロジェクトが適切に文書化されていれば (IF!!!)、次の段階になると、展開する場合、開発者はコード ファイルと共にスクリプトを移行することを忘れないでください。私の $.02
私の意見では、コードは常にデータベースを最初から作成できるはずなので、アップグレードも処理する必要があります。データベースのフィールドをチェックして、スキーマのバージョンを確認し、最新バージョンへのアップグレードを処理する必要があります。
私は幸運に恵まれました：http：//anantgarg.com/2009/04/22/bulletproof-subversion-web-workflow/
作者はデータベースのバージョニングワークフロー（PHPスクリプトを使用）を持っていますが、これはまともです。
ほとんどすべてのプロジェクト内にフォルダー migrations/ があり、いわゆる「アップ」および「ダウン」スクリプト (sql) があります。すべての開発者は、独自のアップ/ダウン スクリプトを作成し、テスト環境に対して検証する義務があります。
移行用のツールやフレームワークは他にもありますが、テストする時間がありません...
いくつかは次のとおりです: DoctrineDB、rails migrations、propel (私は思う...)、capistrano もそれを行うことができます..
私たちは基本的に Senad と同様のアプローチをとっており、開発者が変更を入れるリポジトリに changes.sql ファイルを維持しています。
QA サーバーへのテスト展開を実行します。
db へのスクリプト化された変更を使用してアプリが qa で正常に動作することを確認したら (つまり、changes.sql や参照などに db の変更を含めるのを誰も忘れていません)、次のことを行います。
すべての展開は自動化されたスクリプトを介して実行されるため、再現できるようになりました。
この助けを願っています
一部のフレームワークには、データベースのアップグレードを処理するツールがあります。たとえば、Rails の移行は非常に優れています。お使いのプラットフォームで利用できる便利なツールがない場合は、開発データベースへの変更のスクリプトを作成してみてください。
私の会社では、いくつかの大規模なプロジェクトでこのモデルを使用しています。X がアプリケーションのデプロイされたばかりのバージョンであり、最新の開発バージョンと変わらない場合。たとえば、バージョン x + 1 という名前のスクリプト用の新しいディレクトリを作成し、それを subversion リポジトリに追加します。開発者が開発データベースに変更を加えたい場合、変更を行う「1 - does something.sql」という名前の .sql スクリプトを作成し (変更は破壊不能でなければなりません)、それを保存して開発データベースで実行します。彼は Web アプリ コードと SQL スクリプトをコミットします。各開発者は同じことを行い、スクリプトの実行順序を維持します。バージョン X+1 をデプロイする必要がある場合は、x+1 Web アプリ コードとスクリプトを運用サーバーにコピーし、データベースをバックアップします。
その後、新しい (x + 2) sql スクリプト ディレクトリを開き、手順を繰り返します ...