Docker 持续集成 SQL Server 变更
在持续发布 SQL Server 变更的过程中，Docker 需要做的有两件事：
1 Docker 不会持久性保存数据，将数据库存储文件与 Docker 隔离，指向外围的数据文件，是第一件事。通过添加 volume 可以完成； 2 Docker 能保障的是数据库的运行环境，而我们在发布一次又一次的数据库变更时，更新的是实实在在的数据库对象，是内容而不仅仅是软硬件环境（操作系统补丁，或者数据库补丁等）。
image
因此在生成(build)数据库 Docker 镜像的时候，每个阶段都需要翻新上一个版本，即在上一个版本的基础上，应用本次 source code 中的变更，使其生成一个新的镜像，然后发布到各个环境，比如开发，测试甚至生产。
很多公司对于数据库开发规范和发布的做法，有很大的随意性。比如开发人员随意访问这种数据库环境，并且在这些环境上做了很多没有回滚的事务操作。发布数据库的时候，只是根据对象的存在与否而发了增量的变更。此时并不能真正有效的监测到数据库的发布脚本是否正确。一上生产就各种问题。
有了 SQL Server Docker 之后，可以很好的规避这个问题。每一次的变更都是基于上一个版本做增量更新，都会走一遍配置更新和脚本部署更新，对于原来的 DEV（开发环境）,STG（QA 集成化测试环境）,UAT（用户 sign off 环境） 都使用同一个构建的 SQL Server 环境，甚至对于测试数据（构建到 SQL Server Docker 里面去）也能每个平台保持一致，因此不会出现有了bug 无法重现的情况。只要把 SQL Server Docker 基于某一个开发版本重构建一次（其实每次的构建都会随着开发版本保留下来），所有环境立马相同，bug 也就无处遁形了。
总结一下， SQL Server Docker 的好处大约有：
1 构建一次，到处运行，保障了 DEV, STG, UAT 配置与数据的一致性 2 时刻保持与应用开发版本的步调一致
