？背景在一次会议上，开发人员表示希望能够获得在SIT环境下修改MySQL模式的权限。即无需任何审查，您可以随意执行SIT环境中的任何SQL。首先要说明根本问题，SIT环境是一个综合测试环境。n大于10。该环境目前只支持自动化部署。UAT环境和PROD环境的部署方式相同。接下来我想解释一下为什么我反对开发者在这个环境下随意修改Schema。我举几个常见的例子：SIT环境的users表中name字段的长度是50，而SIT环境是100。对于生产环境，用户设置了一个长度为80的name值。这时候你不能在SIT环境中重现；有一天你发现生产环境中的某个功能很慢。慢的。经过分析，发现该表没有建立索引。原来是开发者在发布生产环境时忘记提供添加索引的SQL。上面的例子，说到底就是环境不一致的问题。这些都是软件工程中非常常见的问题。环境不一致的问题不仅出现在SQL层面，还存在于构建环境层面和运维层面。解决方案SQLschema不一致可以通过codereview+versioncontrol来解决。从SIT环境开始，每条SQL变更都要经过codereview，每一条SQL都是版本控制的。这个版本控制并不是说可以放在Git仓库里，但是SQL的版本也一定要明确。我们可以通过Flyway来实现这一点。下图是Flyway对SQL文件的命名规范：通过Flyway，我们可以清楚的知道MySQL在不同环境下的schema版本，环境一致和不一致，很容易知道。以上就是从技术上解决环境不一致的问题。此外，作者还有其他的考虑，即文化的考虑。在一个工程化程度不高的团队里，经常会听到这样的话：我SIT测试没问题！为什么生产环境会出现问题？我可以在本地构建，为什么不能在Jenkins上构建？这种情况下，有意无意地隐含了一层意思：我没问题，是你的问题。不管你承认不承认。这个意思对团队的影响是：环境一致性的问题是运维的问题，不是开发的问题。开发者只需要自己写代码，什么都不用管。说白了，随便拖到哪里，任由别人收拾。我们已经知道这种开发和运维完全隔离的方式是低效的，就不用再讨论了。但是开发的同学会觉得按照上面的方法修改schema效率会更高——codereview+versioncontrol。想一想，如果写一个函数，不可能一次性把性能写对。然后，模式将被反复修改。每次修改schema都要进行codereview和versioncontrol，非常麻烦。归根结底，开发的问题就是反复调试的过程，应该只出现在自己本地的开发环境中，而不应该出现在影响到大家的SIT环境中。真实情况应该是你有90%以上的把握在部署到SIT环境之前你已经正确地完成了手头的工作。集成测试环境应该用于集成测试，而不是用于调试开发。毕竟，许多开发人员分不清测试和调试之间的区别。如果出现意外，则此时再次“调试”。不过这种场景的出现应该是很少见的。如果经常出现，应该定义为开发者自己的问题。然而开发说：我在本地启动一个应用调试，只是为了连接各种依赖，比如MySQL，其他服务，服务发现中间件等等，怎么办？这时候肯定会有人提出解决方案：我们也应该搭建一个让开发自得其乐的开发环境。为什么说“必有人”。是因为我这些年经历过5、6支球队，每次去一个球队，球队里的人都会提起。其实提出这个方案的人就是偷懒，自己不建，让别人建。作者反对搭建这样的开发环境，并不是因为搭建开发环境会增加DevOps的工作量。相反，快速搭建环境是DevOps的责任。作者真正的原因是：引入这样一个没有版本控制的开发环境，实际上是引入了另一个环境不一致的问题。等到集成测试环境出现问题的时候，开发人员会条件反射地说：我在开发环境没问题。对于开发问题，上面提到的开发问题应该由开发自己来解决。我认为团队更高效的解决方案是：推广单元测试。这可以减少集成测试的需要；提供方便本地开发的脚本，比如一个docker-compose.yaml可以启动本应用的所有依赖；这样每个应用程序都应该能够独立运行而不依赖于其他应用程序。例如，如果A正在调用B，我们应该能够确保当A启动时，B也必须启动。这就需要我们实现良好的解耦。后记维护环境的一致性需要团队中所有的人共同实现。不应仅由环境的建设者维护。
