如何使用 Oracle 数据库自动化源代码控制

Question

我在一个具有数百个模式和多个开发人员的 Oracle 实例中工作。我们有一个开发实例，开发人员可以在其中集成他们的工作，然后再进行测试或生产。

我们希望对在这个集成开发数据库中运行的所有 DDL 进行源代码控制。目前，这是通过我们在对数据库进行更改后手动运行的产品 Red Gate 完成的。 Redgate 发现架构中的内容与上次签入源代码管理的内容之间的更改，并制作差异脚本并将其放入源代码管理中。

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

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

我似乎看不到任何可以简单地用于执行此操作的现有软件。

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

Answer 1

我们在 PL/SQL 函数、python 脚本和 shell 脚本的帮助下做到这一点：

• PL/SQL 函数可以生成整个模式的 DDL 并将其作为 CLOB 返回
• python 脚本连接数据库，获取 DDL 并将其存储在文件中
• shell 脚本运行源代码管理以添加修改（我们在这里使用 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

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

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

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

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

Answer 3

在数据库版本控制领域工作了 5 年（在 DBmaestro 担任产品管理总监）并担任了超过 20 年的 DBA，我可以告诉您一个简单的事实，即您不能将数据库对象视为您处理您的 Java、C# 或其他文件并将更改保存在简单的 DDL 脚本中。

有很多原因，我将仅举几例：

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

还有很多，但我想你明白了。

我发现可行的方法如下：

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

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

Answer 4

（我为 Redgate 开发 Oracle 工具） 实际上，使用 Schema Compare for Oracle 的工具，您已经可以满足我的要求。

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

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

我认为这一切都很好:)