如何解决版本控制默认的安装/自定义触发器和存储过程
| 我是一家小公司的开发人员,我们正在努力实现一致的变更控制。我遇到非开发人员在生产安装中调整存储过程和触发器的问题。当我们应用升级时,它们的更改将被覆盖,因为它们已经超出了开发团队用来验证数据库更改已合并到源代码管理中的过程。 您如何建议从技术和个人角度解决这个问题? 编辑1:对我们当前流程的一些了解可能会帮助实现这一目标。我们正在使用一个持续集成服务器(TeamCity)来生成安装工件,并在签入时标记svn。我正在使用NMigrations在应用修订时管理架构和sp / trigger更改。不幸的是,这超出了我阻止非授权模式更改的能力,因此我很想找到一种设计模式,该模式允许可覆盖的触发器/ sp定义。解决方法
您需要明确分开:
源代码管理管理
发布管理
如果发布环境通过严格的ACL保护,从而防止任何人被正式任命部署和更改内容,则无法对产品进行调整。
如果该部署过程是自动化的,则所有更改都将通过适当的渠道进行,因为任何人都知道一个简单的“按钮”过程就足以部署此修补程序。
但是,如果在源代码管理中获得该修复程序并进行部署很复杂,那么通常直接在prod中进行调整是结果...
,限制更改存储过程和触发器的权限,尤其是在生产上。继续进行,让他们首先知道,这样他们就不会蒙蔽双眼,但是显然可以保护生产免受所有未经授权的更改。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。