>在sql文件中编写更改脚本并将其附加到TFS工作项.
>这项工作经过同行评审
>当工作准备好进行测试时,sql就会在QA上运行.
>这项工作经过QA测试
>当工作准备好生产时,sql将在生产数据库上运行.
这个问题是它非常手动.如果开发人员忘记,它依赖开发人员记住附加sql或同行审阅者捕获它.有时,它最终成为发现问题的测试人员或QA部署人员.
第二个问题是,如果两个单独的任务更改同一个数据库对象,您有时最终需要手动协调更改.这可能只是它的方式,但似乎应该有一些“标记”这些问题或其他东西的自动方式.
我们的设置：我们的开发工作室充满了具有丰富数据库经验的开发人员.我们的项目非常注重数据库.我们主要是.NET和MS sql商店.目前,我们正在使用MS TFS工作项来跟踪我们的工作.这对于代码更改很方便,因为它将更改集链接到工作项,因此我可以确切地了解迁移到QA和生产环境时需要包含哪些更改.我们目前没有使用数据库项目,但可能会在未来切换到该项目(可能这是答案的一部分).
解决方法
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 Ws中的3个.
CREATE TRIGGER [trgAuditDDL] ON DATABASE FOR DDL_DATABASE_LEVEL_EVENTS AS INSERT INTO AuditDDL(EventData,EventUser) SELECT EVENTDATA(),original_login() GO
我包含一个insert语句来记录补丁的开头以及补丁的结尾.在补丁之外发生的事件是需要考虑的事情.
例如,“patch 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
Earlier version previously posted on Server Fault.
在符合SOX和PCI-DSS的环境中,您永远无法访问生产服务器.因此,脚本需要事先清楚并运用.更新脚本顶部的注释包括新表,存储过程,函数等列表,以及已修改表,函数等的列表.如果数据被修改,请解释正在修改的内容及其原因.
A secondary problem is that you sometimes end up needing to manually coordinate changes if two separate tasks change the same database object. This may just be the way it is but it still seems like there should be some automated way of “flagging” these issues or something.
我从未遇到过让我们自动跟踪的工具.以前的雇主使用“数据库所有者”的原则 – 只有一个人亲自负责数据库.此人不是唯一一个针对该数据库的开发人员,而是所有更改都必须通过它们.这相当好地保持了变化不会相互碰撞和破坏.
