Real-world Challenges of Team Development with Oracle APEX, SQLcl, and Liquibase: A Starting Point for Discussion
Source: Dev.to
In modern CI/CD, the goal is simple: 1 Jira Ticket = 1 Pull Request. Every commit should be clean, isolated, and automated. 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”
- Accept manual selection as the “tax” we pay for using Working Copies.
- Rely on strong processes and checklists to reduce human error during the manual staging phase.
- 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.