DBの変更を開発環境からQA、実稼働環境に移行する良い方法は何ですか？現在、私たちは：

1. SQLファイルの変更をスクリプト化し、TFS作業項目に添付します。
2. 作品は査読済みです
3. 作業のテストの準備が整うと、QAでSQLが実行されます。
4. 作業はQAテスト済み
5. 作業の準備が整ったら、SQLを運用データベースで実行します。

これに関する問題は、それが非常に手作業であるということです。開発者がSQLを添付することを覚えている開発者、または開発者が忘れた場合にそれをキャッチするピアレビューアーに依存します。場合によっては、問題を発見したテスターまたはQAデプロイヤーになることがあります。

2番目の問題は、2つの別々のタスクが同じデータベースオブジェクトを変更する場合、変更を手動で調整する必要が生じる場合があることです。これは単なる方法かもしれませんが、これらの問題または何かに「フラグを立てる」自動化された方法があるべきであるように見えます。

私たちのセットアップ：開発ショップには、DBの経験が豊富な開発者がたくさんいます。私たちのプロジェクトは非常にDB指向です。私たちは主に.NETおよびMS SQLショップです。現在、作業を追跡するためにMS TFS作業項目を使用しています。これは、変更セットを作業項目にリンクし、QAおよび実稼働環境に移行するときに含める必要がある変更を正確に見つけることができるため、コードの変更に便利です。現在DBプロジェクトを使用していませんが、将来的にはそれに切り替える可能性があります（おそらくそれは答えの一部です）。

私はソース管理システムに非常に慣れており、私のためにこのようなことをやっていて、SQLにも同じことをしたいと思っています。

VS環境では、常にデータベースプロジェクトを使用して更新スクリプトを実装してきました。スクリプトには、「DatabaseUpdate17.sql」や「PriceUpdateFebruary2010.sql」などの想像を絶する名前を使用する傾向があります。それらをデータベースプロジェクトとして使用すると、それらをTeam Serverのタスク、バグ（およびコードレビューを行った場合も同様）に結び付けることができます。また、スキーマに対する変更のコレクション専用のテーブル（各権限を持っている）を各データベースに含めます。

CREATE TABLE [dbo].[AuditDDL](
    [EventID] [int] IDENTITY(1,1) PRIMARY KEY NOT NULL,
    [EventData] [xml] NULL,                    -- what did they do
    [EventUser] varchar(100) NOT NULL,         -- who did it
    [EventTime] [datetime] DEFAULT (getdate()) -- when did they do it
    )
GO

まあ、それは6 Wのうち3つを処理します。

CREATE TRIGGER [trgAuditDDL]
ON DATABASE 
FOR DDL_DATABASE_LEVEL_EVENTS 
AS
INSERT INTO AuditDDL(EventData, EventUser)
SELECT EVENTDATA(), original_login()
GO

パッチの開始と終了を記録するためのinsertステートメントを含めます。パッチの外で発生するイベントは、検討することです。

たとえば、「パッチ17」の「パッチの開始」挿入は次のようになります。

INSERT INTO [dbo].[AuditDDL]
           ([EventData]
           ,[EventUser])
     VALUES
           ('<EVENT_INSTANCE><EventType>BEGIN PATCH 17</EventType></EVENT_INSTANCE>'
           ,ORIGINAL_LOGIN())
GO

インデックスが再構築されたときにもキャッチするため、これらのイベントをクリアするために、毎月以下を実行する必要があります。

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"ALTER_INDEX")]') =1
GO

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"UPDATE_STATISTICS")]') =1
GO

以前にServer Faultに投稿された以前のバージョン。

SOXおよびPCI-DSS準拠の環境では、運用サーバーにアクセスすることはありません。そのため、スクリプトは事前に明確にして実行する必要があります。更新スクリプトの上部にあるコメントには、新しいテーブル、ストアドプロシージャ、関数などのリストと、変更されたテーブル、ストアドプロシージャ、関数などのリストが含まれています。

2番目の問題は、2つの別々のタスクが同じデータベースオブジェクトを変更する場合、変更を手動で調整する必要が生じる場合があることです。これは単なる方法かもしれませんが、これらの問題または何かに「フラグを立てる」自動化された方法があるべきであるように見えます。

これを自動的に追跡できるツールに出会ったことはありません。以前の雇用主は「データベース所有者」の原則を使用していました-個人的にデータベースを管理しているのは一人だけです。このデータベースに対して作業する開発者はこの人だけではありませんが、すべての変更はそれらを経る必要があります。これは、変更が互いに衝突したり損傷したりするのを防ぐためにかなりうまく機能しました。

SQLソース管理を見たことがありますか？これを使用して、SQL ServerをTFS / SVN / VaultまたはVSSに接続できます-http ://www.red-gate.com/products/sql-development/sql-source-control/

別の解決策は、PowerDesigner、ERWinなどを使用して、データベースの変更を設計および管理することです。

PowerDesignerでデータベースをモデル化するポリシーへの移行を開始しています。データベースの構造/コードへのすべての変更はモデルで行われ、ソース管理にチェックインされ、データベースから変更を実装するためにモデルから変更スクリプトが生成されます。これらの変更スクリプトもソース管理にチェックインされます。大きな変更はピアレビューされており、PowerDesignerは組み込み機能を使用してこれを非常に簡単にします。

PowerDesignerはデータベース以上のものをサポートする汎用モデリングツールであるため、要件の管理、概念図、物理図、アーキテクチャ図（OOMも同様）などの作成に使用し始めています。基本的に、ソフトウェアエンジニアリングプロセス。

（PowerDesignerを開発したSybaseとは一切関係ありません-そこに投入すると思っただけです）。

DBゴースト

DB Ghostはデータベースを管理するための私のお気に入りのツールです。

利点

1. データベース内のすべてのオブジェクトは、ソース管理のスクリプトとして保存されます。
2. 「静的データ」（ルックアップテーブルデータ）もスクリプト化できます。
3. ソース管理は手動で更新するか、「モデル」開発データベースのスクリプトを作成して更新できます。
4. ソース管理（静的データを含む）のスクリプトから（迅速に）データベースを構築できます。
5. 本番インスタンスを含むデータベースのインスタンスに変更をデプロイできます。
   • 「スクリプトから作成された」「データベースの構築」を既存のデータベースと比較して、変更スクリプトを生成できます。
   • ビルドデータベースと運用データベースなど、データベースの2つのインスタンス間で変更を自動的に同期するようにDB Ghostに指示できます。

[4]は、ローカルの変更を行ったり、異なる環境に個別のインスタンスを作成するのに特に便利です。実際、データベースに影響を与える機能やバグごとに個別のデータベースを作成するのは非常に簡単です。

詳細

明示的な変更または移行スクリプトを維持するよりも、それを使用する主な利点は、明示的な変更または移行スクリプトを維持する必要がないことです。ほとんどの場合、データベースの「現在のバージョン」だけを維持できます。移行スクリプトを管理する面倒な点の1つは、簡単な表示方法がないことです。たとえば、テーブル内の列のリスト（移行スクリプトに基づく）です。もちろん、いくつかの変更は明示的な移行として行う必要がありますが、個別のスクリプトとして処理するのに十分簡単です。

データベースを（一連の）スクリプトとして管理でき、新しいインスタンスをすばやく作成できることの特に良い結果は、重要なデータベースコードのユニットテストが非常に簡単（そして非常に楽しい）であるということです。ユニットテストにはtSQLtを使用します。

他のDBMSにも同様のツールがあればいいのにと思います。

ほとんどのDBAにとってはやり過ぎだと思います。

データベースの変更（およびDBの変更のみ）を追跡するためにRuby on Railsを使用することを検討しましたか。アプリを実行したり、Rubyコードなどを記述したりする必要はありません。しかし、移行のスタイル（呼び出し方法）が非常に便利であることがわかりました。http：//guides.rubyonrails.org/migrations.html

Sql Serverもサポートされていますが、JRuby + JDBCを使用する必要がある場合があります。