1

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

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

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

4

2 回答 2

0

您需要清楚地分开：

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

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

于 2011-05-23T21:37:57.293 回答
0

限制更改存储过程和触发器的权限，尤其是在生产环境中。继续让他们先知道，这样他们就不会措手不及，而是清楚地保护生产免受所有未经授权的更改。

于 2011-05-23T21:39:11.273 回答