A A deploy pipeline imports your APEX app while the rest of the team keeps working in the Builder. Until APEX 26.2 there was no supported way to lock the application from code, so most of us flipped the build status to Run Only and hoped for the best. APEX 26.2 ships a real lock API. I upgraded a clone of a local APEX 26.1 database and tested what it actually does, next to everything else APEX calls a lock. It is #JoelKallmanDay today, the day the Oracle community publishes in memory of Joel Kallman, who led the APEX team for many years and it is missed by many. Here is my contribution. Four things that look like a lock Application lock – the Builder lock on the whole app. Only the developer who locked it can edit or unlock it ( docs ). Visible in apex_applications. Page locks – one developer per page, Builder only, no public API. Visible in apex_application_locked_pages. Build status – Run Only keeps developers out of the Builder. Not a lock, but the only thin...
Y You want to change one page and test it before anybody else sees it. With APEXlang on 26.1 you have two options and both are not great. Import into the real app, and you overwrite it (everybody's work in it, not just your page). Or import into a plain copy under another id, and you get an app that has no idea where it came from: you can't easily compare it with the original, and half of your business logic breaks because the app id changed. The old loop Currently, I test every page in a plain copy of the app, one per job. It works, but look at what it costs: the copy is a whole-app import, and so is the delivery into the real app afterwards the copy has no link to the original, so "what did I change?" is a git diff, never something APEX can answer the copy has its own application id, so everything keyed by the app id (settings, roles, translations, logs) misses we need a freshness check before the real import, so we don't revert somebody else...