如何使用Oracle数据库自动化源代码管理

Question

我在一个拥有数百个模式和多个开发人员的Oracle实例中工作。我们有一个开发实例，开发人员可以在测试或生产之前集成他们的工作。

我们希望在此集成开发数据库中运行所有DDL的源代码管理。目前，这是通过我们在对数据库进行更改后手动运行的产品Red Gate完成的。 Redgate查找模式中的内容与上次检查到源代码控制的内容之间的更改，并创建差异的脚本并将其置于源代码控制中。

然而，问题当然是运行regdate可能需要一些时间，人们不经常运行或根本不进行小的更改。此外，redgate一次只能查看一个模式，并且针对所有模式手动运行它以确保它们是最新的非常耗时。但是，如果不能依赖源代码控制代码，它就变得不那么有用......

似乎理想的是拥有一些可以定期（甚至每天一次）的软件，或者当由DDL运行时触发，更新源控件（最好是其他团队使用的github）模式。

我似乎无法看到任何可用于执行此操作的现有软件。

这样做有问题吗？ （没有必要解决多个开发人员在同一天覆盖彼此工作的问题，因为我们在单独的流程中对此进行了覆盖）是否有人这样做？谁能推荐一种方法来做到这一点？

Answer 1

我们在PL / SQL函数，python脚本和shell脚本的帮助下完成此任务：

• PL / SQL函数可以生成整个模式的DDL并将其作为CLOB
返回
• python脚本连接到数据库，获取DDL并将其存储在文件中
• shell脚本运行Source Control来添加修改（我们在这里使用Bazaar）。

您可以在PasteBin上看到脚本：

• PL / SQL函数在这里：http://pastebin.com/AG2Fa9zL
• python程序（schema_exporter.py）：http://pastebin.com/nd8Lf0gK
• shell脚本：

shell脚本：

python schema_exporter.py
d=$(date +%Y-%m-%d__%H_%M_%S)
bzr add
bzr st | grep -q -E 'added|modified' &&  commit -m "Database objects on $d"
exit 0

此shell脚本配置为每天从cron运行。

Answer 2

对我而言，您的工作方式似乎是倒退的：开发人员以无序的方式对数据库运行DDL，然后您需要一个自动化工具来推断运行的更改（和DDL）。

如果您执行以下操作，则可以更好地控制该过程：

• 开发人员将DDL编写为SQL脚本，最好使用Flyway（http://flywaydb.org/documentation/migration/sql.html）等迁移工具。
• 迁移脚本已签入版本控制
• 定期针对数据库运行迁移脚本（例如，通过迁移工具）

在此工作流程中，只能通过自动迁移脚本更改数据库，并且不允许任何人手动执行更改。这对你有用吗？

Answer 3

（我为Redgate开发了Oracle工具） 实际上使用这些工具你已经可以考虑使用Schema Compare for Oracle了。

您可以在UI中或通过命令行比较多个模式 - 我认为您所追求的是自动执行命令行工具，该工具可以创建差异脚本，在源和目标之间进行同步（实时，快照或脚本）和生成报告。

您可以自动命令行同步到脚本文件夹，这是您的源代码检出，然后运行命令提交更改。

我认为这一切都很好：）

Answer 4

在数据库版本控制空间中工作了5年（作为DBmaestro的产品管理总监）并且作为DBA工作了二十多年，我可以告诉你一个简单的事实，你不能对待数据库处理Java，C＃或其他文件时的对象，并将更改保存在简单的DDL脚本中。

原因很多，我只列举一些：

• 文件存储在开发人员的PC本地和他/她的更改 使得不影响其他开发者。同样，开发人员不是 受到她的同事所做的改变的影响。在数据库中这是 （通常）并非如此，开发人员共享同一个数据库 环境，因此提交给数据库的任何更改都会影响 他人。
• 使用签入/提交更改/发布代码更改 等（取决于您使用的源控制工具）。在那时候， 插入开发人员本地目录中的代码 源控制存储库。想要获得最新信息的开发人员 代码需要从源代码管理工具请求它。在数据库中 变更已经存在并影响其他数据，即使它不是 签入存储库。
• 在文件签入期间，源代码管理工具会执行冲突 检查是否修改了同一文件并由另一个文件签入 您修改本地副本期间的开发人员。再来一次 在数据库中没有检查这个。如果你改变了一个程序 您的本地PC，同时我修改了相同的程序 代码形成我的本地PC然后我们覆盖彼此的变化。
• 代码的构建过程是通过获取标签/ latest来完成的 将代码版本添加到空目录然后执行构建 - 编译。输出是二进制文件，我们在其中复制＆amp;更换 现有。我们不关心以前的事情。在数据库中我们不能 我们需要维护数据来重新创建数据库！还有 部署执行在构建中生成的SQL脚本 过程
• 执行SQL脚本时（使用DDL，DCL，DML（用于静态） content）命令）你假设当前的结构 环境在创建脚本时匹配结构。如果不， 然后，当您尝试添加新列时，您的脚本可能会失败 已经存在。
• 将SQL脚本作为代码处理并手动生成它们将导致 语法错误，数据库依赖性错误，不是的脚本 可重复使用，使开发，维护， 测试那些脚本。另外，这些脚本可以运行在 环境与你运行的环境不同 上。
• 有时版本控制存储库中的脚本不匹配 被测试的对象的结构，然后是错误 在生产中发生！

还有更多，但我认为你得到了照片。

我发现作品如下：

1. 使用强制执行的版本控制系统 对数据库对象的签出/签入操作。这将 确保版本控制存储库与代码匹配 签入时，它会在签入中读取对象的元数据 操作而不是手动完成的分离步骤。这也允许 几个开发人员同时在同一个数据库上工作 防止他们意外地覆盖彼此的代码。
2. 使用影响分析，利用基线作为一部分 比较以识别冲突并确定是否存在差异（何时 比较源控件之间的对象结构 存储库和数据库）是一个真正的变化，起源于 发展或差异源于不同的道路和 然后应该跳过它，例如不同的分支或紧急情况 固定。
3. 使用知道如何为许多人执行影响分析的解决方案 模式一次，使用UI或使用API​​最终 自动化构建和部署过程。

我写的一篇文章发表于here，欢迎您阅读。