是否有“最佳实践”类型的过程供开发人员遵循以进行数据库更改?

Bet*_*zel 31 sql-server-2008 process source-control

将数据库更改从开发环境迁移到 QA 到生产环境的好方法是什么?目前我们:

  1. 在 SQL 文件中编写更改脚本并将其附加到 TFS 工作项。
  2. 工作经过同行评审
  3. 当工作准备好进行测试时,SQL 在 QA 上运行。
  4. 作品经过 QA 测试
  5. 当工作准备好进行生产时,SQL 将在生产数据库上运行。

问题在于它非常手动。如果开发人员忘记了,它依赖于开发人员记得附加 sql 或同行评审员捕获它。有时,最终发现问题的是测试人员或 QA 部署人员。

第二个问题是,如果两个单独的任务更改同一个数据库对象,您有时最终需要手动协调更改。这可能只是它的方式,但似乎仍然应该有一些“标记”这些问题或其他东西的自动方式。

我们的设置:我们的开发商店充满了具有丰富数据库经验的开发人员。我们的项目非常面向数据库。我们主要是一家 .NET 和 MS SQL 商店。目前我们正在使用 MS TFS 工作项来跟踪我们的工作。这对于代码更改非常方便,因为它将更改集链接到工作项,因此我可以准确地找出在迁移到 QA 和生产环境时需要包含哪些更改。我们目前没有使用 DB 项目,但将来可能会切换到该项目(也许这是答案的一部分)。

我非常习惯于我的源代码控制系统为我处理这样的事情,并希望我的 SQL 也有同样的事情。

Tan*_*ena 17

在 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
Run Code Online (Sandbox Code Playgroud)

好吧,这解决了6 W 中的 3

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

我包含了一个插入语句来记录补丁的开始和补丁的结束。补丁之外发生的事件是需要研究的。

例如,“补丁 17”的“开始补丁”插入看起来像:

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

由于它还会在重建索引时捕获,因此您需要每个月左右运行以下命令以清除这些事件:

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
Run Code Online (Sandbox Code Playgroud)

之前发布在 Server Fault 上的早期版本

在符合 SOX 和 PCI-DSS 的环境中,您将永远无法访问生产服务器。因此,脚本需要事先明确并进行练习。更新脚本顶部的注释包括新表、存储过程、函数等的列表以及修改表、存储过程、函数等的列表。如果数据被修改,解释修改的内容和原因。

第二个问题是,如果两个单独的任务更改同一个数据库对象,您有时最终需要手动协调更改。这可能只是它的方式,但似乎仍然应该有一些“标记”这些问题或其他东西的自动方式。

我从来没有遇到过可以让我们自动跟踪的工具。以前的雇主使用“数据库所有者”的原则 - 一个并且只有一个人亲自负责数据库。此人不会是针对该数据库工作的唯一开发人员,而是所有更改都必须通过他们。这在防止更改相互冲突和损坏方面非常有效。


小智 7

你看过 SQL 源代码控制吗?您可以使用它将 SQL Server 连接到 TFS/SVN/Vault 或 VSS - http://www.red-gate.com/products/sql-development/sql-source-control/