背景

在一次会议中，开发同学表达了希望能拿到执行修改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也必须启动。这要我们做到很好的解耦。

后记

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