我是一个团队中的DevOps工程师和软件工程师，几个月前，开发人员从拥有中央Oracle数据库转向了将数据库置于个人笔记本电脑上的CentOS VM上。从中央数据库转移的目的是减少对DBA的依赖性，并消除由于数据不一致而引起的问题。

与团队中的每个人共享并确保数据库同步的计划是，每个人人将与所有人共享更改脚本。问题是我们使用Skype进行通信（我们只是设置了松弛度，但尚未完全使用它），尽管人们有时会张贴DB更改脚本的文本，但有些人可能会忽略它。另一个问题是某些开发人员会错过发布更改。此外，新版本已部署到生产环境中，而没有部署在测试和演示环境中。

这对我们构成了严峻的挑战，尤其是我本人，他最近负责确保我们的演示部署能够与生产部署同步。
大多数同步问题都与由于缺少更改脚本或缺少数据库对象而导致数据库缺乏同步有关。 Oracle是我们的首选数据库。

在演示环境中的典型部署是一个非常痛苦的过程，其中涉及测试应用程序，并且由于缺少数据库表列，函数，存储的proc而出现问题时，我们必须寻找丢失的数据库对象，将它们应用到数据库，然后继续直到解决所有问题。

如何解决此问题，以确保顺利，轻松且耗时更少的部署？将我们的应用程序迁移到Docker是否可以解决数据库同步问题以及开发人员缺乏纪律性的问题？我们可以采取什么措施来改善这一领域？

#1 楼

我会将模式管理集成到应用程序本身（或与之一起）。

对模式的任何更改都应随应用程序代码一起提交（因此也应加标签）。

这个问题中已经列出了很多可能性：哪些实践或工具可以实现数据库的连续部署

通过这种工具，使用诸如h2或一个中央数据库，并在启动时让应用程序检查架构版本（存储在数据库中），以允许在应用程序启动时获取更新的数据库架构。

这不会解决您的学科问题，并且可能会创建新的学科，因为这通常带有严格的架构版本控制，可以使用预提交的钩子来强制执行版本，但这是一项艰巨的工作。

#2 楼

在我们公司中，我们在VCS（Git）中管理我们的应用程序代码，我们使用的大多数应用程序都从应用程序随附的安装脚本中安装其核心数据库。

如果我们必须为其中一个客户扩展或定制应用程序，这涉及到必须扩展数据库或进行数据库自定义，然后我们将在代码中附带安装脚本，该脚本将通过应用程序的数据库层/包装器/驱动程序执行数据库操作。 />
这样，一旦代码合并到VCS存储库中，每个将签出此代码的开发人员都将检索这些数据库更改。同样，在代码合并之后，这些数据库更改将最终出现在每个环境（测试，UAT和生产节点）上，这样所有数据库更改都将顺利推出。

这是一种易于实现的方法。如果您需要更高级的管理功能，则还可以使用特定于数据库的源代码控制工具。