为什么我不允许开发人员修改测试环境的MySQL Schema

在一次会议中,开发同学表达了希望能拿到执行修改SIT环境MySQL schema的修改权限。也就是不经过任何review,都可以随意的在SIT环境执行任何的SQL。

为什么我不允许开发人员修改测试环境的MySQL Schema

背景

在一次会议中,开发同学表达了希望能拿到执行修改SIT环境MySQL schema的修改权限。也就是不经过任何review,都可以随意的在SIT环境执行任何的SQL。

根本问题

首先要说明下,SIT环境是集成测试环境。n 大于10。这个环境目前只允许通过自动化部署实现部署。UAT环境和PROD环境都采用同样的方式部署。

接下来,我想说明我为什么反对开发人员随意在此环境上进行Schema的修改。我举一些常见的例子:

  • SIT环境的的users表中的name字段长度是50,而SIT环境的是100。上生产环境用,用户设置了一个长度80的name值,这时,你在SIT环境中是无法重现的;

  • 有一天发现生产环境的某个功能很慢,从监控看,是某条SQL很慢。经分析发现该表没有建索引。原来是开发人员发布生产环境时,忘记提供增加索引的SQL了。

  • 以上例子,说到底就是环境不一致的问题。这些是软件工程中非常常见的问题。环境不一致的问题除了在SQL层面发生,还会在构建环境层面、运维层面发生。

    解决方案

    SQL schema的不一致问题,我们通过code review+版本控制来解决。就是从SIT环境开始,每次SQL变更都必须经过code review,每条SQL都进行版本控制。

    这个版本控制不是说放到Git仓库里就可以的,还必须明确的指定SQL的版本。这一点,我们可以通过Flyway实现。下图是Flyway对于SQL文件的命名规范:

    为什么我不允许开发人员修改测试环境的MySQL Schema

    通过Flyway的方式,我们可以明确的知道不同环境的MySQL的schema的版本,环境一致不一致,可以很容易的知道。

    以上是从技术上解决环境不一致的问题。除此之外,笔者还有别的考虑,即文化上的。

    在工程化程度不高的团队,你经常会听到这样的话:

    我在SIT测试是没有问题的啊!为什么在生产环境就出问题?我在本地构建是可以的,为什么在Jenkins上就不行?

    这样的话,都有意无意地暗含着一层意思:我没有问题,那是你的问题。不管你承认不承认。

    这层意思会对团队所带来的影响是:环境一致性问题是运维的问题,不是开发的问题。开发人只管自己写完代码就什么可以不管了。说难听点,就是只管自己随地拉,让别人来收拾。

    这种将开发与运维完全隔离的方式,我们已经知道是低效的了,不需要再讨论。

    但是,开发的同学会觉得按照以上方式——code review+版本控制——修改schema更低效。想想,你写一个功能,不可能一次性能写对,那么,就会反复的修改schema,每修改一次schema,都要进行一次 code review和版本控制,多麻烦。

    开发的问题

    说到底那是这个反复调试的过程,应该只出现在自己的本地开发环境,而不应该出现在对于大家都有影响的SIT环境。真实情况应该是你有90%以上的把握,正确完成了手头上的工作后,再部署到SIT环境。集成测试环境应该是用于集成测试的,而不是用于调试开发的。说到底不少开发,分不清测试与调试之间的区别。

    如果真的出现意外,那么,这时再“调试”。但是这种场景的出现应该是少数的。如果频繁出现,那么应该定义成是开发人员自己的问题了。

    但是,开发说:我本地启动一应用来进行调试,就是要连各种依赖的啊,比如MySQL、其它服务、服务发现中间件等。怎么办?

    这时,一定会有人提出一个解决方案:我们应该还要搭建一个开发环境,可以让开发尽情搞的环境。

    为什么说“一定会有人”。是因为,这些年经历过5,6个团队,每到一个团队,团队里的人都会提。其实,提出这个解决方案的人是在偷懒,自己不搭建,让别人搭建。

    笔者反对搭建这么一个开发环境,并不是因为搭建一个开发环境,会增加DevOps的工作。恰恰相反,能快速的搭建一个环境是DevOps的职责。

    笔者真正的理由是:引入这么一个没有版本控制的开发环境,其实是引入另一个环境不一致性问题。在上集成测试环境后出现问题,开发人员又会条件反射地说:我在开发环境好好的啊。

    开发的问题,应该由开发自己解决

    以上说的开发问题,我觉得对于团队更高效的解决办法是:

  • 推广单元测试。这样可以减少集成测试的需要;

  • 提供方便本地开发的脚本,比如一个docker-compose.yaml能启动所有的这个应用的依赖;

  • 使每个应用都应该能不依赖其它应用独立运行的。比如正在A调用B这样的关系,我们应该能做到A启动时不应该于B也必须启动。这要我们做到很好的解耦。

  • 后记

    环境的一致性的维持需要团队中所有的人共同实现。不应该只是由环境的搭建者来维持。

    原文链接:https://mp.weixin.qq.com/s?__biz=MzU1Njk2NjkxNA==&mid=2247484295&idx=1&sn=649bc3755fdfa15750b14c4e0fe99773&utm_source=tuicool&utm_medium=referral

    版权声明:本文(即:原文链接:https://www.qin1qin.com/catagory/6689/)内容由互联网用户自发投稿贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 630367839@qq.com 举报,一经查实,本站将立刻删除。

    (0)
    上一篇 2022-07-29 10:20:44
    下一篇 2022-07-29 10:20:54

    软件定制开发公司

    相关阅读

    发表回复

    登录后才能评论
    通知:禁止投稿所有关于虚拟货币,币圈类相关文章,发现立即永久封锁账户ID!