絶えず変化するデータベースディメンションをどのように処理しますか？

9

過去2か月ほどの間、データベース内のリリース管理を処理するためのソリューションまたはプラクティスを探していました。これを処理するための最良のプロセスとして人々が見ているものを探しています。

データベースには3つの環境があります。

開発
ユーザー受け入れテスト（UAT）
製造

問題は、開発データベース内のいくつかのものに変更を加えて展開するときが来ていることです。一部の機能はUATにリリースする準備ができていない可能性があります。

最近、すべてのエンティティを（通常のコミットで）格納するためにRed Gate SQLソースコントロールを使用し始めました。

私はチェンジセットに基づいて行くことを考えていました（つまり、チェンジセットXからすべてがUATにプッシュされていると言います）、つまり、混乱を招く可能性のあるデプロイを行う直前に、人々がコードをソース管理にチェックインしているだけです（特に人々は忘れっぽいからです）。変更セットのアプローチに伴うもう1つの問題は、修正が必要なストアドプロシージャにバグがある場合、変更セット番号は最終的にリビジョンの最大変更セットの範囲外になるため、必要に応じて最大のチェンジセットからデータベースを再作成します。バグを再度プッシュします。

プロセスに関する提案はありますか？

ありがとう

— ジャダー
ソース

データベーススクリプトが「実際の」コードと同じソース管理にないようです。どうしてこれなの？それを「ソースコード」として扱い、個々のブランチと一緒に置くことができますか？

— Mike M.

現在、スクリプトの開発バージョンのみをソース管理に保存しています。UAT/ Productionはどちらもアクティブな開発と同期していません。ソース管理の各スクリプトは、開発者がコミットを行うたびに更新されます。個々のブランチの問題は、誰もが使用する1つの集中型データベースがあることです（大きな変更の場合は、個別のデータベースをブランチ化します）。

1

リリースのブランチを作成し、リリースに関連する変更のみをコミットすることができます。他のすべての変更はトランクに行う必要があります。これを実現するには、2つの開発データベースが必要です。これは問題でしょうか？

それはかなりすぐに時代遅れになる可能性が高いようです。番号？私のプロジェクトの1つでは、データベースの大規模なオーバーホールの最中であるため、データベースの変更されていないバージョンでアクティブな開発が引き続き行われるように、そのプロジェクトを1つに分岐しました。しかし、分岐バージョンがますます古くなっていくのが毎日わかりますが、それが大丈夫かどうかはわかりません...これまでこのような状況に対処する必要がありませんでした。

— ジャッダ

5

マイグレーション

リポジトリ内にあり、アプリとともにタグが付けられたアップとダウン。

スキーマを変更してスキーマのバージョンを更新するSQLフラットファイルでDIYすることもできます。あなたが本当にしなければならないすべては：

マイグレーションをソースコードの隣に置きます。それらはバージョン管理され、一緒にタグ付けされている必要があります
すべての環境で常に管理された変更（移行）を使用する
どのような環境でもアドホックな変更を許可しない

まあ、devで開発の変更を行うことはできますが、変更を取得したら、常にdbを吹き飛ばして、マイグレーションでそれを再構築する必要があります。

— ダイエット
ソース

スクリプトにバグが見つかった場合はどうなりますか？SQLスクリプトに戻って更新しますか？

— ジャッダ'29年

1

いいえ、新しいマイグレーションを作成します（これにより、スキーマのバージョンが上がります）。データベース内のスキーマバージョンを確認することで、修正が展開されたことを確認できます。

— 2011年

ご協力ありがとうございました。一見すると、これは非常に強固なアプローチであり、分岐戦略に似ています。

— ジャッダ

2

ソース管理！

svn / git / p4を経由せずに開発バイナリを直接本番環境にデプロイしない場合、なぜデータベースだけでそれを行うのでしょうか？開発者がローカルの変更をテストするためのプライベートインスタンスを取得しますが、開発データベースに移動する必要がある場合は、チェックインされたddlファイルを経由する必要があります。これらのddl変更を自動的に適用するツールを作成することもできます（これを正しく行うための既存の方法は知りません）。

dbスキーマの変更に関する制限があり（sqlplus-> issue ddlが不要です）、厳密なアカウント制御（全員へのddlアクセスなし）を行うと、管理が容易になります。

— スブサンカラスブラマニアン
ソース

1

残念ながら、私たちのデータベースは大きすぎて、開発者間で受け渡しできないため、プライベートセッションを実行できません。それだけでなく、チームベースの開発に傾いているようにも見えません。現在、私は2つをつなぐUI作業について人々と話し合いながら、バックエンド開発を行っています。まず、すべての変更をチェックインしてから、データベースで最新の状態に更新する必要があります。これはかなり面倒な作業のようです。

— ジャッダ

開発DBが本番DBと同じサイズでなければならないのはなぜですか？それらは同じスキーマを持つことができ、すべてのデータを含む特別な負荷テストフリートを持つこともできますが、ローカルの開発データベースは小さい場合があります。これにより、データ漏洩の懸念なども防止されます-理論的には、製品データは開発に影響を与えるべきではありません。

— Subu Sankara Subramanian、

すべてのデータは、クライアントから提供されたファイルを処理し、必要なデータに変換するデータロードプロセスを通じてロードされます。とにかく開発中にすべてのデータロードを検証する必要がある場合、開発データと製品データを分離することは不可能です。同じサイズである必要はないと思いますが、作成するレポートが意味のある情報を生成するためには、同等の量のデータが必要です。

— judda '28年

DB全体を複製する必要はありません。Oracleでは、すべてのユーザーが独自のスキーマを持ち、1つのアプリケーションスキーマがあります。アプリケーションスキーマ内のすべてのオブジェクトのパブリックシノニムを作成します。次に、すべてのユーザーが自分のスキーマ内のオブジェクト（テーブル、SP）を変更できます。ユーザーが自分で接続する場合は、オブジェクト名が使用されます。スキーマにないオブジェクトの場合、同義語が使用されます。これが私たちの働き方です。

— softveda '28年

0

移行を使用するという提案をフォローアップ...おそらくRuby on RailsやEntity Framework 4.3のような移行をサポートするO / RMを使用することです。（通常）変更セットの場合のように適用する移行を選択することはできません。

別の実行可能なオプション（Microsoftスタックを使用している場合は、プラットフォームについて言及したことがない）は、Visual StudioデータベースツールでSQLを管理することです。組み込みのリファクタリング（列の名前変更/削除など）があり、モデルの検証を行います。たとえば、ストアドプロシージャが存在しない列を参照している場合は、通知されます。

— マイケル・ブラウン
ソース