最近进行了系统的一次大的升级，由于要进行升级执行的数据库的脚本很多，所以发布时一不小心执行了一个不该执行的脚本。事后虽然我们及时的进行了补救，但是
仍然让系统的业务停滞了近2个小时。
因而有必要对数据库脚本的登记和管理及数据库脚本的发布流程进行下梳理。
首先就体现在数据库的脚本登记上：
1.脚本登记一定要按照项目登记在统一的文件夹，文件夹的名称要按照统一的规范来命名，让发布人员一眼就能根据文件夹的名称来区分。
因为我们目前一般都会有多个项目并行，虽然都是围绕一个产品在进行开发，但是项目的启动和终结是有先后顺序的，所以 一般一个项目
的脚本都应该在一个文件夹下，同时由于项目是在迭代进行的，不是一次就将所有的功能就发布完了，所以一定要在项目文件夹下再有子文
夹来区分，比如有些正在开发的功能的脚本是不能执行到PRD数据库的，因此我们在项目文件夹下应该有2个文件，一个是开发和测试使用的
另外一个是专门用来发布PRD时使用的。每次发布PRD前都会确定发布的功能的，这样我们就可以从开发和测试的文件夹中整理一份脚本来
用于发布。
2.每次登记脚本都要写清楚这段脚本的用途和说明，创建者，登记时间，执行了那些数据库，如果有注意事项，则需要加以说明，比如这段脚本
只能在那个数据库执行，或者不能在 那个库执行。同时普通的数据库脚本和存储过程及函数要分开登记在不同的脚本文件中。同时脚本的登记
实现增量登记，即如果你修改了某个存储过程，请将修改后的存储过程直接登记在专用于登记存储过程的脚本文件中，不要修改以前登记的存储
过程。
其次就是我们数据库脚本的发布的流程了：
1.每次将对要发布PRD版本时，需要发布的脚本要提前要和发布该项目测试版人员进行确认清楚，因为发布项目测试版本的同时会非常清楚测试版本
执行脚本的情况，而且也会有记录，这样可以保证执行的脚本都已经通过了测试，这样才可以保证发布时脚本的正确执行。
2.如果是遇到大的版本升级，系统升级的前一天，或者半天，先拿一个最新的正式版的备份，做一次模拟升级，将可能遇到的问题尽可能的暴露出来，
这样可以进一步的降低风险。
3.数据库脚本升级执行前，尽可能的先做备份，然后再执行。
另外还有一点要注意的是冲突。
由于我们针对同一个产品在并行开发多个项目，因此会有像AppID，MenuID，及其他一些基础数据项的ID，比如OrderTypeID等需要新增的情况，这时候
要保证我们执行脚本时不发生ID或者主键冲突的情况，那就是要我们在写这些脚本时，都在一个全局的数据库中去占位，先将这个ID的位给占了，然后在
登记，这样就不会出现这种情况了。
转载于:https://www.cnblogs.com/kevinGao/archive/2012/12/15/2819710.html