问题描述
作为一名 DevOps 工程师和团队中的软件工程师，我所在的团队几个月前将中央 Oracle 数据库迁移到了各自开发人员笔记本上的 CentOS 虚拟机中。这个从中央数据库迁移的目的是减少对数据库管理员的依赖，并消除由于数据不一致性引起的问题。
我们共享和确保团队中每个人的数据库同步的计划是，每个人都将变更脚本分享给所有人。问题是，我们使用 Skype 进行沟通（我们刚刚设置了 Slack，但还没有完全开始使用），尽管有时人们会发布数据库变更脚本的文本，但某些人可能会忽略它。另一个问题是，有些开发人员会忘记发布变更。此外，新版本在没有在测试和演示环境部署的情况下发布到生产环境。
这对我们构成了严重的挑战，特别是最近我负责确保我们的演示部署与生产部署同步。大多数同步问题涉及由于缺少变更脚本或缺少数据库对象而导致的数据库不同步。我们首选 Oracle 作为数据库。
在演示环境中，典型的部署过程是一个非常痛苦的过程，涉及测试应用程序并且在由于缺少数据库表列、函数、存储过程引起的问题时，我们必须查找缺失的数据库对象，将它们应用到数据库中，然后继续，直到解决所有问题。
解决方案
集成模式管理
一种解决方法是将模式管理集成到应用程序本身（或与之一起）。
任何对模式的更改都应与应用程序代码一起提交（并因此也进行标记）。
以下是一些可能性：What practices or tools enable Continuous Deployment of Databases
使用这类工具，可以在应用程序启动时检查数据库模式版本（存储在数据库中），从而在应用程序启动时获取更新的数据库模式。
这种方法不会解决纪律问题，并可能引发新问题，因为通常会严格版本化模式。强制执行版本化可以使用预提交钩子来完成，但这需要一些努力。
代码管理数据库变更
在我们公司，我们将应用程序代码存储在版本控制系统（Git）中，并且大多数我们使用的应用程序都会从随应用程序一起提供的设置脚本中安装其核心数据库。
如果我们需要为客户扩展或定制应用程序，这涉及到扩展数据库或进行数据库定制，那么我们将伴随我们的代码提供一个设置脚本，该脚本将通过应用程序的数据库层/封装/驱动程序执行数据库操作。
这种方式，一旦代码合并到版本控制系统存储库中，检出此代码的每个开发人员都会检索到这些数据库更改。此外，代码合并后，这些数据库更改将出现在每个环境（测试、UAT 和生产节点）中，从而顺利地推出所有数据库更改。
这是一种易于实施的方法。如果需要更高级的管理功能，您还可以深入研究专用于数据库的源代码控制工具。
总结
通过将模式管理集成到应用程序中，或者通过代码管理数据库变更，您可以在多个环境中实现平稳、轻松和更少耗时的部署。这有助于解决数据库同步问题，并提高开发人员的纪律性。在实施时，您还可以根据团队的需求选择适合您的方法，以确保更加流畅的部署流程。