私の 4 人の開発チームは、しばらく前からこの問題に直面しています。
場合によっては、同じデータ セットを処理する必要があります。そのため、ローカル コンピューターで開発を行っている間、開発データベースはリモートで接続されています。
ただし、他の開発者のデータを踏む操作をデータベースで実行する必要がある場合があります。つまり、関連付けを解除します。これには、ローカル データベースが適しています。
このジレンマを回避するためのベスト プラクティスはありますか? 「データの SCM」ツールのようなものはありますか?
奇妙なことに、SQL の挿入/削除/更新クエリのテキスト ファイルを git リポジトリに保持すると便利ですが、これはすぐに非常に遅くなる可能性があると思います。
皆さんはこれにどのように対処しますか？
私の質問「ソース管理からデータベースを構築するにはどうすればよいですか」が役立つ場合があります。
基本的に、共有リソース（データベースなど）を効果的に管理することは困難です。他の開発者、テスター、プロジェクトマネージャーなど、複数の人々のニーズのバランスを取る必要があるため、難しいです。
多くの場合、個々の開発者に、他の開発者やテスターに影響を与えることなく開発と単体テストを実行できる独自のサンドボックス環境を提供する方が効果的です。ただし、これは万能薬ではありません。これらの複数の個別の環境を時間の経過とともに相互に同期させるメカニズムを提供する必要があるためです。開発者がお互いの変更（データ、スキーマ、コードの両方）を取得するための合理的な方法を持っていることを確認する必要があります。これは必ずしも簡単ではありません。優れたSCMの実践は役に立ちますが、それを実現するにはかなりのレベルの協力と調整が必要です。それだけでなく、各開発者に環境全体の独自のコピーを提供すると、ストレージのコストと、それらの環境の管理と監視を支援する追加のDBAリソースが発生する可能性があります。
考慮すべきいくつかのアイデアは次のとおりです。
統合テストには、ローカルの開発者データベースと単一のマスター データベースを使用します。作成スクリプトは SCM に保存します。1 人の開発者が、「ゴールデン マスター」スキーマに基づく SQL スクリプトの更新を担当します。開発者は、必要に応じてローカル データベースに変更を加えたり、統合 DB のデータから必要に応じて入力したり、インポート プロセスを使用したり、ツール (この場合は Red Gate Data Generator) を使用してデータを生成したりできます。必要に応じて、開発者はローカル コピーを消去し、必要に応じて作成スクリプトと統合データから更新できます。通常、データベースは統合テストにのみ使用され、単体テスト用にモックアウトされるため、同期を維持する作業量が最小限に抑えられます。
この件に関する Scott Allen の見解をご覧になることをお勧めします。彼が書いた一連のブログは、私の意見では素晴らしいものです。 データベース作業の 3 つのルール、ベース ライン、 変更スクリプト、 ビュー、ストアド プロシージャなど、 分岐とマージ。
私はこれらのガイドラインを多かれ少なかれ個人的な変更を加えて使用し、それらは機能します。
以前は、データウェアハウスに関連し、必要に応じてクライアントサイトにインストールするように設計された製品に取り組んでいました。その結果、ソフトウェアは「インストール」（主に必要なデータベーススキーマの作成と通貨/国コードなどの静的データの入力）を実行する方法を知っていました。
この情報はコード自体に含まれており、プラグイン可能なSQLアダプターがあるため、このコードをインメモリデータベース（HSQLを使用）で機能させるのは簡単でした。その結果、「実際の」ローカルサーバー（OracleまたはSQL Server）に対して実際の開発作業とパフォーマンステストのほとんどを実行しましたが、プロセス固有のインメモリDBに対してすべての単体テストとその他の自動化されたタスクを実行しました。
この点で非常に幸運なことに、一元化された静的データに変更があった場合は、インストール手順のアップグレード部分に含める必要がありました。そのため、デフォルトでは、SCMリポジトリに保存され、開発者によってチェックアウトされ、通常のワークフローの一部としてインストールされます。振り返ってみると、これは提案されたDB変更ログのアイデアと非常に似ていますが、もう少し形式化されており、その周りにドメイン固有の抽象化レイヤーがあります。
このスキームは非常にうまく機能しました。なぜなら、誰もが他の人の足を踏むことなく、最新の静的データを使用して完全に機能するDBを数分で構築できるからです。インストール/アップグレード機能が必要ない場合に価値があるかどうかはわかりませんが、データベースの依存関係が完全に無痛になったので、とにかくそれを検討します。
私は2つのことのうちの1つをしました。どちらの場合も、他のユーザーと競合する可能性のあるコードで作業している開発者は、独自のデータベースをローカルで実行するか、開発データベースサーバーで別のインスタンスを取得します。
@tvanfossonが推奨したものと同様に、データベースを最初から構築できるSQLスクリプトのセットを保持します。
明確に定義された定期的に、すべての開発者データベースは、使用しているデータの種類に応じて、本番データのコピー、または本番の縮小/匿名化されたコピーで上書きされます。
このアプローチはどうですか：
「クリーンなデータベース」用に別のレポを維持します。リポジトリは、テーブルの作成/挿入などを含む sql ファイルになります。
Rails を使用して (どの git リポジトリにも適応できると確信しています)、アプリケーション内のサブモジュールとして「クリーン db」を維持します。SQL ステートメントを使用してローカル dev データベースにクエリを実行するスクリプト (おそらく rake タスク) を作成します。
ローカル データベースをクリーンアップする (そして新しいデータに置き換える) には:
git submodule init
git submodule update
それから
rake dev_db:update ......... (or something like that!)
LBushkinが彼の答えで言ったことすべてに同意します。SQL Server を使用している場合、複数の開発環境間で変更を簡単に共有できるソリューションが Red Gate に用意されています。
http://www.red-gate.com/products/sql_source_control/index.htm
DBA が複数の開発環境を許可することを困難にするストレージの問題がある場合、Red Gate にはこれに対する解決策があります。Red Gate の HyperBac テクノロジを使用すると、開発者ごとに仮想データベースを作成できます。これらは通常のデータベースとまったく同じように見えますが、バックグラウンドでは、共通のデータが異なるデータベース間で共有されています。これにより、開発者は、SQL Server の非現実的な量のストレージ スペースを占有することなく、独自のデータベースを持つことができます。
過去に、私はこれをいくつかの方法で処理しました。
1 つは、データベースを作成および設定する SQL スクリプト リポジトリです。これはまったく悪いオプションではなく、すべてを同期させることができます (この方法を使用しない場合でも、DB がソース管理されるようにこれらのスクリプトを維持する必要があります)。
もう1つは（私が好む）、誰も接続していないサーバー上に「クリーンな」開発データベースの単一のインスタンスを持つことでした。開発者は、開発データベースを更新する必要があるとき、「クリーンな」データベースを開発コピーにコピーする SSIS パッケージを実行しました。その後、他の開発者の足を踏むことなく、必要に応じて開発データベースを変更できました。
テーブルとプロシージャを作成/更新するために使用するデータベース メンテナンス ツールがあります。データが入力された最新のデータベースを持つサーバーがあります。
選択したとおりに操作できるローカル データベースを保持しますが、「ベースライン」に戻る必要がある場合は、サーバーから「マスター」のバックアップを取得し、ローカルに復元します。
列/テーブル/プロシージャを追加する場合は、ソース管理に保持されている dbMaintenance ツールを更新します。
時々、それは苦痛ですが、それはかなりうまく機能します。
nHibernate などの ORM を使用する場合は、開発者の LOCAL 開発データベースにスキーマとデータの両方を生成するスクリプトを作成します。
開発中にそのスクリプトを改善して、典型的なデータを含めます。
配置前にステージング データベースでテストします。
エンド ユーザーのために、実稼働データベースを UAT データベースに複製します。開発者はそのデータベースにアクセスできません。
すべてのテーブルを削除して再作成し、テスト データを挿入するのに数秒もかかりません。
スキーマを生成する ORM を使用している場合、作成スクリプトを維持する必要はありません。