Org locking and deployment timing for change sets
Key Takeaway
While an inbound change set is deploying, the target org is locked against metadata changes until the deployment finishes, but users can still read and write data.
Deploying a change set locks the target org against metadata changes, so the timing of a deployment matters. Because of the lock, and because some deployments take a long time, admins plan when to validate a change set and when to deploy it.
What the deployment lock blocks
An inbound change set is a change set as it appears in the target org, which is the org that receives and deploys it. While an inbound change set is deploying, the target org is locked until the deployment finishes.
The lock blocks metadata changes, not data. Users can still read and write data in the org, so a deployment to production doesn't stop them from working with records. However, no one can make setup changes that would modify the metadata, so an admin who wants to change setup in that org has to wait until the deployment finishes.
Your team starts deploying an inbound change set to production at 7 PM. While the deployment runs, the support team keeps creating and closing cases, because the lock doesn't block data. At the same time, Dana, another admin, opens Setup to edit a validation rule on the Case object. Editing a validation rule is a setup change that modifies metadata, so Dana has to wait until the deployment finishes.