新しいバージョンをプッシュする際のデータベーススキーマ変更の処理

重い開発の時代には、データベーススキーマは急速かつ継続的に変化し、ベータビルドへの毎週のプッシュが来るまでに、スキーマは大きく変化したため、唯一可能な賢明なオプションは、可能な限りすべてのテーブルを破棄することですdevデータベースから新しいバージョンをコピーします。明らかに、これは起動後は機能しません。プロダクションデータの削除は災害のレシピであるため、あるバージョン/リビジョンから別のバージョン/データベーススキーマへの変更を管理するための戦略はどこにあるのでしょうか。

私が見つけたまたは経験したもの：

1. あるデータベースから別のデータベースへの直接的な核ダンプ（今私がやっていること）
2. スクリプトまたは手動で実行されるSQLステートメントを含むUPDATE.sqlファイルを維持します。
3. アクティブなデータベースで対応する「db-schema-version」値を持つupdate.phpファイルを維持する

3番目のオプションは最も賢明な方法のようですが、不完全に構築されたSQLクエリがスクリプトの途中で失敗し、データベースが半分更新された状態のままになり、バックアップの復元が必要になる可能性がまだあります。

それは問題ではないように見えますが、チームとしてphpMyAdminを使用しているため、実際に実行されます。実行されたSQLステートメントをコピーしてupdate.phpファイルに貼り付けることを忘れないでください。別のページに移動したら、SQLステートメントを手動で書き直すか、変更を元に戻して再度実行する必要があります。

私が望んでいるのは、確立された開発ワークフローに影響を与えないソリューションですか？

自動化。自動化。自動化。

あなたは明示的なDBバージョン番号で正しい軌道に乗っていますが、さらに一歩進んで、どのスキーマに対して動作することが予想されるかを正確にコードに明示させます（たとえば、実際のDDLスクリプトをコミットしてアップデーターに解析させることにより） ）; その後、更新時に、データベースメタデータと、必要に応じてINSERT / DROP / ALTERを介して既存のスキームを検出するだけで、どのバージョンから更新するかに関係ありません。（データベース自体に明示的なバージョン番号を保持し、インストーラーでスキーマ履歴全体を配信することもできます。これにより、スキーマを検出する必要さえなくなります。）

更新SQLスクリプトの潜在的な構文エラーは問題ですが、アップデーターが正しいDDLステートメントのみを生成できることを確認することにより、それを解決できます。（正式な証明は、エンタープライズソフトウェア開発ではほとんど価値がありません-少なすぎる保証のための労力が大きすぎます-しかし、データベースの整合性は数少ない例外の1つであると感じています：実稼働データの保護が非常に優れているため、特に無人インストールで動作する必要がある場合は、1回限りの先行投資のほとんどが正当化されます。

データベーススキーマのバージョン管理を使用する方法です。各バージョンには、データベースに対する変更が1つだけ、または少なくとも全体として元に戻すことができる変更があります。DBDeployは、それを自動化する優れたツールです。

私が役に立つと学んだことは次のとおりです。

1. 常にローカルで変更をテストし、それを使用してコードをテストします。ALTER合格だけでは不十分です
2. 最初に変更を行うために同期する必要があります-「数字を取得」できるシンプルなウィキページは、私のチームにとって非常に役立ちました。
3. 壊れた変更を修正しようとしないでください、それを無効にするために新しいカウンター変更を追加してください、それは非常に無痛です
4. コードはその変更に依存します-バグ追跡システムの問題とDBの変更を必ずリンクしてください。これはデプロイ時に非常に役立ちます。
5. DBの変更をCIに含める-コミット時に変更をCIデータベースに適用します。また、データベースを使用するテストがある場合は、コミット時に実行します。

phpMyAdminを使用しているので、MySQLも使用していると思います。

MySQL WorkbenchのEERモデル図をご覧ください。それらは、スキーマの保守と更新において、私にとって大きな助けになりました。

最初に、モデルをデータベースソースと同期できます。そのため、ダイアグラム内の変更はALTER TABLEコマンドとしてプッシュされます。これにより、ダイアグラムでスキーマの変更を実行し、必要に応じて開発データベースに更新をプッシュしながら、常に最新の状態に保つことができます。

次に、データベースソースからEER図をリバースエンジニアリングできます。これは、開発データベースに変更を加え、差分を計算するので本番データベースを更新することで便利です。

第三に、「update.sql」ファイルに入るSQLの作成を支援するために使用できます。

短所：

データベースのトリガーと制約は、同期アップデーターの問題です。物事の正しい順序を知らないようです。外部キー制約は多くの場合エラーを生成しますが、これは生成するSQLを編集することで解決できます。

これはデータ移行ツールではありません。純粋にスキーマを超える変更には、カスタムSQLが必要です。

http://south.aeracode.orgを見てください。これはDjango（Pythonフレームワーク）用のDB移行ライブラリですが、次のとおりです。

1. あなたはそれから素晴らしいアイデアを得ることができます（そしておそらくPHPクローンを見つけることもできます）
2. 実際にDjangoの残りの部分から独立して使用して、PHP / MySQLアプリのテーブルを管理できます。

また、スキーマ更新スクリプトを生成できます。また、ほとんどの場合、変更の取り消しを自動的に処理します。