版本控制默认安装/自定义触发器和存储过程

Posted 2023-03-06

【中文标题】版本控制默认安装/自定义触发器和存储过程

【英文标题】：Versioning default install/customized triggers and stored procedures

【发布时间】：2011-05-23 21:28:34

【问题描述】：

我是一家小公司的开发人员，我们正在努力实现一致的变更控制。我遇到了非开发人员在生产安装中调整存储过程和触发器的问题。当我们应用升级时，它们的更改会被覆盖，因为它们已经超出了开发团队用来验证数据库更改是否已纳入源代码控制的流程。

您建议如何从技术和个人角度解决这个问题？

编辑 1：我们当前流程的一些背景知识可能会对此有所帮助。我们使用持续集成服务器 (TeamCity) 在签入时生成安装工件和标签 svn。当我们应用修复时，我使用 NMigrations 来管理模式和 sp/trigger 更改。不幸的是，阻止未经授权的架构更改超出了我的能力范围，因此我希望找到一种允许可覆盖触发器/sp 定义的设计模式。

【参考方案1】：

你需要清楚地分开：

源代码控制管理

release management

如果发布环境受到严格的 ACL 保护，防止任何人被正式任命部署和更改内容，那么在 prod 中进行调整是不可能的。 如果是deployment process is automated，那么所有更改都将通过proper channel，因为任何人都知道一个简单的“按钮”过程就足以部署修补程序。

但是，如果在源代码管理中修复并部署它很复杂，那么结果通常是直接在 prod 中进行调整...

【讨论】：

在生产环境中绝对不可能进行调整。不幸的是，我们的流程还没有成熟到足以限制这一点。

【参考方案2】：

限制更改存储过程和触发器的权限，尤其是在生产环境中。请先让他们知道，以免他们措手不及，但要明确保护生产免受所有未经授权的更改。