Access and locks
Last updated
Was this helpful?
A shared environment can only be safely used by one thing at a time — two deployments running at once, or a person changing config while a release deploys, will collide. codev prevents this by giving every environment an exclusive-access lock. While an environment is in use it is locked; anyone else who needs it waits in a queue and is let in automatically when it frees up.

The Access & Locks section of an environment's page shows the active lock and the waiting queue. A lock records who holds it, the reason, and an expiry; while it is held the environment shows In use. The holder — or an owner — can Release lock to free it early.
Most locks are taken automatically. When a flow deploys to an environment — a build deploying to a Test environment, a release deploying to production, an org-drift check — it locks the environment for the duration of its work and releases it when finished. This is why a release can sit in Waiting: it is queued behind whatever currently holds the environment, and proceeds the moment that lock is released. You can watch this on the Flows page.

To use an environment yourself — to test a change, debug an issue, or deploy something manually — request exclusive access from the environment's page. Choose how long you need it (the access duration) and a reason — Deployment, Testing, Maintenance, Configuration, Bug Fix, or Data Update.
If the environment is available, access is granted immediately and the environment is locked to you for the duration you chose.
If it is in use, you join the waiting queue. codev grants you access automatically when the current holder releases the lock or their lease expires — you do not have to keep checking.
Release the lock from the environment's page when you are done so the next person, or the next deployment, can proceed. A lock also expires on its own at the end of its lease, so a forgotten lock does not block an environment indefinitely.
Last updated
Was this helpful?
Was this helpful?