背景
在一次会议中，开发同学表达了希望能拿到执行修改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文件的命名规范：
通过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