1

これは、すべての人が別々のデータベースを持っている開発者のチームで開発している人たちへの質問です。ソース管理やその他のツールを使用してデータベースをバージョン管理しているため、開発データベースはデータベースの最新バージョン（スキーマ、データ、SP、関数など）に自動的に更新されます。

OK素晴らしい！ちょっと待って！ソフトウェアのバージョン4.0で開発しているが、バグを修正するためにブランチを3.2ブランチに切り替える必要がある場合はどうなりますか？スキーマは（ほぼ確実に）今では非常に異なっている可能性があります...

変更スクリプトと一緒にロールバックスクリプトを作成するために余分な労力を費やした場合、これは機能する可能性があると思います。しかし、それは大変な作業のように思えます-それは本当に価値がありますか？

4

2 に答える 2

1

新しい3.2ブランチのデータベースを作成し、3.2ブランチのコードで作業しながら、それを操作する方がはるかに簡単です。各開発者が作業するデータベースを1つだけ持っていることを要求することは私には合理的ではないようです。

于 2010-09-10T15:53:53.183 に答える
0

私は手足を使って、データベースをバイナリとしてバージョン管理していると仮定しますか？すべてのデータベースアセットが建設的なコード（SQLスクリプトやテキストデータダンプなど）の形式である場合、Markが提案するように、ソリューションは単純です。これらのアセットを開発ブランチの一部として保存します。バージョン3.2で作業するには、ブランチを切り替え、スクリプトの作成とpresto3.2データベースを再実行します。マージは通常のコードと同じくらい簡単です（または、選択したバージョン管理システムによっては同じくらい面倒です）。

このモードで動作するためのいくつかの提案があります：

  • テキストからデータベースインスタンスを作成するのが遅すぎる場合は、すべてのスキーマ/データファイル（またはそのMD5合計）の内容をキーとして、共有ディスクボリュームにキャッシュを作成します。
  • pre-commitフックを記述して、開発者のインスタンスのスキーマとデータのダンプがバージョン管理下にあるものと同じになるようにします。これにより、ユーザーがインタラクティブツールを使用して開発データベースに変更を加えてからコミットするのを忘れることがなくなります。
  • あなたは変更スクリプトについて言及しています。それらを責任として扱います。展開シナリオで必要になる場合がありますが（たとえば、インプレースでアップグレードしたいお客様の場合）、データベースのバージョン履歴から情報を複製します。マーフィーの法則によれば、複製は遅かれ早かれ非同期化を意味します。「diff」を使用して、バージョン管理されたデータベースアセットから変更スクリプトを自動生成してみてください。または、これを達成できない場合は、データベースのアップグレードにいくつかの深刻な単体テストを割り当てます。
于 2010-09-13T09:30:05.193 に答える