深圳幻海软件技术有限公司 欢迎您!

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

2023-02-27

 背景在一次会议中,开发同学表达了希望能拿到执行修改SIT环境MySQLschema的修改权限。也就是不经过任何review,都可以随意的在SIT环境执行任何的SQL。根本问题首先要说明下,SIT环境是集成测试环境。n大于10。这个环境目前只允许通过自动化部署实现部署。UAT环境和PROD

 

背景

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

根本问题

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

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

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

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

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

解决方案

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

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

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

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

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

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

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

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

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

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

开发的问题

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

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

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

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

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

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

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

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

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

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

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

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

后记

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