Dev Environment Reservation Best Practices: A Checklist

Shared environments fail in predictable ways. Someone deploys over someone else. A "quick test" holds the environment all afternoon. A pipeline overwrites a manual QA session. Nobody knows whether the database was reset after the last person used it.

None of these need a big process to fix. They need a handful of decisions made once and written down. This checklist covers those decisions, grouped by stage, with the reasoning for each item so you can skip the ones that don't apply.

Use it when setting up reservations for the first time, or as an audit when the current system has started to fray.

1. Inventory

• List every shared environment by name. Include each dev, QA, staging, UAT and performance environment, even ones "only one team uses."
• List the shared dependencies inside them. A single partner sandbox, one test database, a payment provider test account, an SSO test tenant. These are often the real bottleneck.
• List non-environment shared things. Test devices, licence seats, hardware boards, build machines. They have the same problem and benefit from the same system.
• Mark which items are interchangeable. qa-1 and qa-2 may be a pool; staging-payments may be unique.

Why: you can't coordinate what you haven't named. Most "is anyone using staging?" confusion comes from one word meaning several different things.

2. Naming

• One short, unambiguous name per resource. staging-api, qa-2, pixel-8-test. Lowercase, hyphenated, no spaces.
• Names match what people say out loud. If the team calls it "the payments box," name it payments-box, not env-07.
• Descriptions carry the details. URL, what's deployed there by default, who owns it, any quirks.
• Physical items carry a label with the name. So anyone who sees a device knows what to look up.

3. Ownership

• Every resource has an owning team. They decide disputes and approve destructive changes.
• Holding a lock is not ownership. Locking staging-payments lets you use it; it doesn't let you change its configuration without asking the owner.
• Decide who can create and delete resources. Usually anyone can create; deletion should be limited for important shared items.

4. Durations

• Every reservation has an end time. No open-ended claims. This is the single most important item on the list.
• Busy resources get short defaults. One to two hours for heavily contested environments.
• Quiet resources get longer defaults. A working day for devices or rarely contested environments.
• Long sessions are stated explicitly. Regression suites, soak tests and demos give their own duration when they lock.
• Release early is the norm. Expiry is a safety net, not the plan.

For more on choosing durations and handling handoffs, see lock etiquette.

5. Visibility

• Current holder and end time are visible to everyone. Without asking.
• Visible where the team already works. In your chat tool, not a separate dashboard or a spreadsheet tab nobody opens. Sheets drift the moment someone forgets to update a row.
• Lock and release events post to a channel. So the team has a feed of what's in use.
• Waiters can subscribe to a release. "Tell me when it's free" beats asking every twenty minutes.

6. Contention

• There's a defined way to ask for a resource someone holds. A structured request the holder can approve or reject, not a channel argument.
• Takeovers are for genuine blocks. Incidents, blocked releases, abandoned locks.
• Requests get a fast answer. Approve, or reject with a time.
• Repeated contention triggers a capacity discussion. If the same environment always has a queue, add one or move work to ephemeral preview environments.

7. CI/CD

• Pipelines lock before deploying to a shared environment. The same lock humans use, so a pipeline can't deploy over a manual session.
• Pipelines release in an always-run step. Even when the job fails or is cancelled.
• Pipeline lock durations are slightly longer than the job. So a crashed runner's lock still expires on its own.
• Pipeline-to-pipeline serialisation is handled too. CI concurrency features like GitHub Actions concurrency or GitLab's resource_group stop two pipelines colliding; they don't know about humans, so you need both.

8. Coding agents

• Agents that deploy or run tests against shared environments take locks too. An AI coding agent that runs migrations against staging-db is a user like any other.
• Agents use the same system as people. Through an API or MCP server, so their locks are visible in the same list.
• Agent locks are short and named clearly. So a human seeing the lock knows what's holding it.

9. State and reset

• Document the expected state of each environment. Which branch is "normally" deployed, what seed data exists.
• Decide who resets after use. Either the holder restores it, or a reset job runs on release or nightly.
• Note deviations in the description. If you leave a feature flag on or a migration applied, say so.

10. Review

• Quarterly, look at what's always held and what's never held. Always-held items need capacity; never-held items may be removable.
• Check whether defaults match reality. If most locks run to expiry, defaults are too long or people aren't releasing.
• Remove resources that no longer exist. A stale list erodes trust in the whole system.

Putting the checklist into practice with Lockit

Most of this checklist is policy. The parts that need tooling are items 4 to 8: end times, visibility, alerts, takeovers, and CI and agent access. Lockit is a chat bot built for those parts, in Slack, Discord and Microsoft Teams.

Create and name resources (items 1–2). @Lockit new asks for a name, a description and an optional channel for lock and release updates. For a private channel, invite Lockit first.

Lock, release and list (items 4–5).

@Lockit lock staging-api
@Lockit release staging-api
@Lockit list

On Discord: /lockit lock resource:staging-api duration:2 hours, with plain-language times like till 6pm. On Teams: @Lockit lock staging-api 2 hours, and cards show lock times in each reader's timezone.

Durations with defaults (item 4). A lock's end time is the duration chosen when locking, else the resource's default, else the workspace default, else 48 hours. Defaults can be set per resource and per workspace.

Contention (item 6). When a resource is taken, people see who holds it and until when, with Alert when released and Ask for takeover. The holder gets Release and Approve and Reject Request buttons.

CI (item 7). On paid plans, a REST API at https://api.lockitbot.com/api/locky with an X-API-KEY header locks and releases resources from pipelines:

curl -X POST \
  -H "X-API-KEY: $LOCKIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"userEmail":"ci@yourco.com","duration":30}' \
  https://api.lockitbot.com/api/locky/resources/staging-api/lock

# ... deploy and test ...

curl -X POST -H "X-API-KEY: $LOCKIT_API_KEY" \
  https://api.lockitbot.com/api/locky/resources/staging-api/release

duration is in minutes. API keys are created from Lockit's App Home tab in Slack, and the API works with Slack workspaces only for now. Full reference: API docs. The full pipeline pattern is in locking staging from CI/CD.

Coding agents (item 8). The same key works with Lockit's MCP server at https://api.lockitbot.com/api/locky/mcp, which gives tools to list, inspect, lock, release, create and delete resources and set default durations. It works with Claude Code, Cursor and VS Code. Setup is in the MCP docs, and there's a walkthrough in Lockit MCP with Claude Code.

What it doesn't cover. Lockit doesn't create, reset or destroy environments, doesn't integrate with calendars, and doesn't take reservations for a future date. Items 3, 9 and 10 stay as team policy and your own tooling.

Pricing: free for two resources with unlimited locks and members; Starter is $17/month for up to 100 resources plus API and MCP access; 15-day trial on paid plans. See pricing.

A one-page summary

Area	Minimum standard
Inventory	Every shared environment and dependency listed by name
Naming	Short, spoken names; details in descriptions
Ownership	An owning team per resource
Durations	Every claim ends; short defaults on busy resources
Visibility	Holder and end time visible in chat; updates in a channel
Contention	Alerts for waiting; structured takeover for blocking
CI/CD	Pipelines lock, release in always-run steps
Agents	Agents use the same locks via API or MCP
State	Expected state documented; reset owner defined
Review	Quarterly look at usage and defaults

FAQ

What's the most important item on this checklist?

Every reservation has an end time. Most shared-environment pain comes from claims that never expire, whether that's a message in a channel, a row in a spreadsheet or a role nobody removed.

Do small teams need all of this?

No. A team of five can start with sections 1, 2, 4 and 5: name things, give every claim an end time, and make it visible in chat. Add CI and agent locking when pipelines or agents start touching shared environments.

Should CI use the same reservation system as people?

Yes. CI concurrency controls only coordinate pipelines with other pipelines. If people test manually on the same environment, the pipeline needs to check and take the same lock they do.

Can Lockit reserve an environment for a specific time next week?

No. Lockit locks start when they're taken and end at their end time. For planned windows, use a calendar and lock the environment when the window starts.