In modern CI/CD, the goal is simple: 1 Jira Ticket = 1 Pull Request. Every commit should be clean, isolated, and automated. However, when working with Oracle APEX and database objects in a team environment, achieving this "clean state" is anything but straightforward.
1. Working Copies: Great for APEX, But...
The Approach: Use APEX's native "Working Copies" to branch the application metadata.
The "But": Working Copies only isolate APEX components (pages, items, etc.). They still point to a shared parsing schema.
The Result: When you export your Working Copy, you might have clean APEX metadata, but your database export will still capture every other developer's changes in that shared schema.
2. Liquibase Automation: Great for Schemas, But...
The Approach: Use liquibase generate-schema -split to automate database object exports.
The "But": In a shared schema (e.g., BO_SHARED), Liquibase captures the state of the entire schema.
The Result: If Developer A creates a table for Ticket 1, and Developer B creates a package for Ticket 2, Developer A’s export will automatically include Developer B’s work. Automation is defeated because the developer must then manually identify and git add only their specific files.
3. Separate Schemas: Great for Isolation, But...
The Approach: Give every developer their own schema (DEV1, DEV2, DEV3) for true isolation.
The "But": This breaks the APEX parsing connection.
The Result: Developers cannot easily test their changes within the shared APEX application without first migrating those objects back to a master schema, creating a different kind of integration bottleneck.
4. Git Filtering: Great for Precision, But...
The Approach: Use advanced Git techniques (interactive staging, cherry-picking, or rebasing) to filter out unrelated changes.
The "But": This places a massive manual overhead on the developer.
The Result: We end up using Liquibase as a mere file generator rather than an automation tool. If a developer has to manually reset 48 out of 50 generated files, the "automation" has failed.
The Current Reality: Accepting the Trade-offs
We have concluded that no current approach provides 100% full automation for both APEX and Database objects in a shared environment.
Our Current "Workaround":
We accept Manual Selection as the "tax" we pay for using Working Copies.
We rely on strong processes and checklists to reduce human error during that manual staging phase.
We use Pre-Development Reviews to align on architecture, ensuring that even if the "push" is manual, the logic is sound.
Let’s Discuss
Is there a way to achieve a truly automated, isolated 1-to-1 mapping of Jira tasks to PRs in APEX without separate schemas? Or is the "Manual Selection" bottleneck simply the price of doing business in a shared-database IDE?
How is your team handling the shared schema bottleneck? I’m looking for feedback from anyone who has managed to automate this without the manual overhead.
Top comments (1)
Fully automated 1 Ticket = 1 PR in a shared APEX parsing schema is unicorn-rare, the closest playbook is migration-first DB scripts, strict per-ticket labels/paths, CI guardrails, plus EBR or ephemeral envs. In a shared schema, lean on Liquibase labels + PR checks + path conventions and a lightweight DDL audit to catch only what you actually touched. Go trunk-based with feature flags, run DB migrations before importing APEX, and back it up with targeted utPLSQL smoke/impact tests. Steer clear of generate-schema -split for feature work, if you absolutely must use it, corral it with --diffTypes, --excludeObjects, and ticket-scoped includes. You won’t nuke manual selection entirely, but you’ll shrink it to something small, predictable, and easy to review-goodbye diff chaos.