可能部分同学对DDL和DML不是特别熟悉，但是说到SQL脚本就知道了。DDL用于定义或改变表的结构、数据类型等；DML用于管理数据库中的数据，进行插入、删除和修改。
比如某个需求可能要增加表、增加字段（列）、修改字段类型等，是涉及DDL；某个需求增加/修改了默认配置，是涉及DML。
为什么要关注DDL和DML呢，你是否遇到过这样的情况，在测试环境运行了很多遍的程序，一到生产环境就各种报错，一检查发现是这个配置漏了或者那个数据类型错误。为什么这么简单的脚本总是容易出错呢？因为如果脚本执行没有进行规范，开发可能随手在开发环境和测试环境执行完，就忘记了这回事，一个版本多则长达几个月，少则几天，到投产时开发不可能记得每一个修改的字段类型和增加的配置，这就是为什么这些问题不会在测试环境暴露。即使每次投产前DBA都强调了几遍，上线脚本检查好了再发过来，可投产还是会出现问题。从质量保证的角度看，是不是可以通过一些规范，避免出现类似的问题。
一、对DDL和DML文件进行版本把控
每个版本的DDL和DML文件要统一存放在版本管理库中，一是避免上线脚本的遗漏，二是方便后期回溯。脚本有修改的话也要及时提交修改，确保可获取的版本是最新的。让开发养成及时提交DDL和DML的习惯，而不是由开发各自保存，而且上线前才临时整理汇总，往往容易出现遗漏。
二、测试环境管理
测试环境不能给开发权限，避免开发在测试环境随意修改数据库。可以在提测邮件中将脚本一同附上，统一由测试同学执行。或者需要开发提申请让运维执行脚本。或者仅一个开发有权限在测试环境执行，其他开发有需求的即提交脚本文件。这些都是为了避免开发遗漏脚本，避免测试环境没问题上生产就各种报错。
三、上线脚本抄送给所有项目成员
上线前，可以在投产准备中将上线脚本抄送给所有项目成员，项目组内的其他开发、测试、运维等看到脚本后，如果知道有遗漏的或者中途有修改过的，可以及时提出来要求开发同学补充。
四、上线演练
如果有条件，最好进行一次上线演练，可以是另一套测试环境，或者是验收测试环境，或者是预发布环境等，演练过程和投产过程一致，脚本统一由运维执行。发布后，测试同学或者产品在该套环境进行测试，出现脚本遗漏问题立即找对应负责人补充到投产脚本中。通过演练的方式进行兜底，尽可能确保一次性投产成功。
五、生产问题复盘
如果前面已经做了很多努力，最后还是有遗漏，也不要灰心丧气，通过复盘总结是哪个步骤的疏忽，后面可以怎么改进，流程可以怎么优化，总结经验，放眼未来，永远不只是为了这一次上线。
