sql-server-2008 – 开发人员是否有“最佳实践”类型的流程来跟
将DB更改从开发迁移到QA到生产环境有什么好方法?目前我们: >在SQL文件中编写更改脚本并将其附加到TFS工作项. 这个问题是它非常手动.如果开发人员忘记,它依赖开发人员记住附加sql或同行审阅者捕获它.有时,它最终成为发现问题的测试人员或QA部署人员. 第二个问题是,如果两个单独的任务更改同一个数据库对象,您有时最终需要手动协调更改.这可能只是它的方式,但似乎应该有一些“标记”这些问题或其他东西的自动方式. 我们的设置:我们的开发工作室充满了具有丰富数据库经验的开发人员.我们的项目非常注重数据库.我们主要是.NET和MS SQL商店.目前,我们正在使用MS TFS工作项来跟踪我们的工作.这对于代码更改很方便,因为它将更改集链接到工作项,因此我可以确切地了解迁移到QA和生产环境时需要包含哪些更改.我们目前没有使用数据库项目,但可能会在未来切换到该项目(可能这是答案的一部分). 我非常习惯我的源代码控制系统为我处理这样的事情,并希望对我的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 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的环境中,您永远无法访问生产服务器.因此,脚本需要事先清楚并运用.更新脚本顶部的注释包括新表,存储过程,函数等列表,以及已修改表,函数等的列表.如果数据被修改,请解释正在修改的内容及其原因.
我从未遇到过让我们自动跟踪的工具.以前的雇主使用“数据库所有者”的原则 – 只有一个人亲自负责数据库.此人不是唯一一个针对该数据库的开发人员,而是所有更改都必须通过它们.这相当好地保持了变化不会相互碰撞和破坏. (编辑:晋中站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |