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

Question

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

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

编辑1：我们当前流程的一些背景可能有助于此。我们使用持续集成服务器（TeamCity）来生成安装工件并在签入时标记svn。我在应用修复时使用NMigrations来管理架构和sp /触发器更改。不幸的是，我无法阻止未经授权的架构更改，因此我希望找到一种允许可覆盖的触发器/ sp定义的设计模式。

Answer 1

你需要明确分开：

• 源代码管理
• 的 release management

如果通过严格的ACL保护发布环境，阻止任何人正式指定部署和更改内容，则不应该在prod中调整。 如果deployment process is automated，然后所有更改都将通过proper channel，因为任何人都会知道一个简单的“按钮”进程就足以部署此修补程序。

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

Answer 2

限制更改存储过程和触发器的权限，尤其是在生产过程中。继续让他们先知道，这样他们就不会傻了眼，但显然可以保护生产免受所有未经授权的更改。