Azure Deployment Environments
Design and implement Azure Deployment Environments
The problem: developers need real infrastructure on demand, and central teams need governance. Ticket queues solve the second by destroying the first.
The split
| Role | Owns |
|---|---|
| Platform engineers | Create and manage environment definitions; associate them with projects; assign developer permissions |
| Developers | Create environments on demand from the definitions they are permitted to use |
Governance is applied by environment type — sandbox, testing, staging, production — so a sandbox and a production environment can carry entirely different policy while both remain self-service.
What developers actually get
By default, every environment is created in its own resource group, and project members receive contributor access to those resources. That combination is what makes genuine investigation possible: an isolated blast radius plus enough rights to work.
It is also what makes cleanup tractable — deleting the environment deletes its resource group.
In a pipeline
Environment definitions can be driven from CI/CD, so a pipeline provisions an ephemeral environment, deploys into it, tests, and tears it down. Central dev IT can still track costs, security alerts and environments across projects and dev centres.
Primary sources