团队开发使用 Oracle APEX、SQLcl 和 Liquibase 的真实挑战：讨论的起点

Source: Dev.to

在现代 CI/CD 中，目标很简单：1 Jira 任务 = 1 Pull Request。每一次提交都应该是干净的、隔离的、自动化的。当在团队环境中使用 Oracle APEX 和数据库对象时，实现这种“干净状态”并非易事。

1. Working Copies：适用于 APEX，但…

方法

使用 APEX 原生的 Working Copies 来对应用元数据进行分支。

“但”

Working Copies 只隔离 APEX 组件（页面、项等），它们仍然指向同一个共享的解析模式（parsing schema）。

结果

当你导出 Working Copy 时，可能得到干净的 APEX 元数据，但数据库导出仍会捕获共享模式中其他开发者的所有更改。

2. Liquibase 自动化：适用于模式，但…

方法

使用 liquibase generate-schema -split 来自动导出数据库对象。

“但”

在共享模式（例如 BO_SHARED）中，Liquibase 会捕获整个模式的状态。

结果

如果开发者 A 为任务 1 创建了表，而开发者 B 为任务 2 创建了包，开发者 A 的导出会自动包含开发者 B 的工作。自动化失效，因为开发者必须手动识别并仅 git add 自己的文件。

3. 独立模式：适用于隔离，但…

方法

为每个开发者提供独立的模式（DEV1、DEV2、DEV3），实现真正的隔离。

“但”

这会破坏 APEX 的解析连接。

结果

开发者无法在共享的 APEX 应用中轻松测试自己的更改，除非先将这些对象迁移回主模式，从而产生另一种集成瓶颈。

4. Git 过滤：适用于精确控制，但…

方法

使用高级 Git 技巧（交互式暂存、cherry‑picking 或 rebase）来过滤掉无关的更改。

“但”

这会给开发者带来巨大的手动工作量。

结果

我们最终把 Liquibase 当作普通的文件生成器，而不是自动化工具。如果开发者必须手动重置 50 个生成文件中的 48 个，那么“自动化”已经失败。

当前现实：接受权衡

我们已经得出结论：在共享环境中，没有任何现有方法能够为 APEX 与数据库对象提供 100 % 完全自动化。

我们目前的“变通方案”

• 将手动选择视为使用 Working Copies 必须付出的“税”。
• 依赖严格的流程和检查清单，降低手动暂存阶段的人为错误。
• 在开发前进行评审，以确保架构一致，即使“推送”是手动的，逻辑也必须是可靠的。

让我们讨论

• 是否有办法在不使用独立模式的情况下，实现 APEX 中 Jira 任务到 PR 的真正自动化、隔离的 1 对 1 映射？
• 还是说“手动选择”瓶颈就是共享数据库 IDE 中的业务成本？

你的团队是如何处理共享模式瓶颈的？期待听到任何已经实现自动化且没有手动开销的经验分享。