Azure Deployment Environments: A practical guide

This relatively new service in Azure is positioned as a tool for Platform Engineering teams for providing a secure and well-governed access for dev teams to Azure, in a self-service way. Providing a curated catalogue of validated IaC templates that are written in a compliant way, allowing developers to focus on their applications without worrying about infrastructure, and letting the service deploy the infrastructure on behalf of devs, and easily integrate with their existing CI/CD pipelines or CLI tools.

Let’s explore Deployment Environments in a more practical way and see how it either competes with or complements other offerings (like DevTest Labs) and frameworks such as Azure Landing Zones.

Transcript

1. Deployment environments: A practical guide Azure User Group Norway meetup 9.4.2025 David Pazdera
2. About me • principal solution architect @ Cegal • meetups, conferences, ACP, communities (ALZ, Azure Arc, Bicep, AVM, Terraform in Azure) • GitHub | LinkedIn | Sessionize | SpeakerDeck | X : pazdedav handle • Blog: azurescholar.cloud
3. What are Azure Deployment Environments • part of Azure platform engineering offering with components shared with Microsoft Dev Box • collection of Azure infra resources defined in a template (blueprint) – environment definition • empower dev teams to quickly and easily spin up app infrastructure with project-based templates that establish consistency and best practices while maximizing security. • provides on-demand access to secure environments accelerates the stages of the software development lifecycle in a compliant and cost-efficient way.
4. Not this platform engineering
5. Benefits ✓Standardization and collaboration • share IaC templates in VCS within your organization • collaboration through inner-sourcing ✓Compliance and governance • enforce enterprise security policies ✓Project-based configurations ✓Self-service for devs ✓Integration with your existing toolchain: CI, IDE, CLI
6. Key concepts
7. ADE Overview
8. Platform engineers Publishers, building IDP as a product
9. Platform team responsibility • create and configure a dev center • define environment types • create and manage Catalog(s) with environment definitions • configure subscriptions • create a project in the dev center, add environment ty, allow dev access to the project (assign permissions to devs) • track costs, security alerts • manage environments across projects and dev centers
10. Definitions Catalog • Definitions are are rendered to the Developer portal • IaC template + manifest file (yaml) • Structure of folders
11. Projects and environments mapping deployment subscription ADE Project Environment type: dev Users and groups Deployment identity resources tags: inherited Contributor User Access Admin Reader Deployment Environments User
12. Demo time…
13. Lessons learned • ADE repo structure and ‘AZD compatibility’ • AVM modules for ADE are N/A – reverse engineer ARM template • Issues when using SAMI, but UAMI worked great • Don’t forget to define tags for Project environments
14. Developers Consumers of IDP, benefiting from a great DevEx
15. Responsibility • create environments based on the templates • Developer portal - https://devportal.microsoft.com/ • Az CLI • AZD CLI • build and deploy applications on the infrastructure $params = "{ 'name': 'firstMsi', 'location': 'northeurope' }" az devcenter dev environment create --dev-center-name <devcenterName> --project-name <projectName> --environment-name <environmentName> -- environment-type <environmentType> --environment-definition-name <environmentDefinitionName> --catalog-name <catalogName> --parameters $params
16. Demo time…
17. ADE + AVM: Better together
18. AVM is great but what if you… • need a specific resource composition / module • don't want to publish modules externally, but • don’t want to create and maintain general-purpose resource modules, or • need to temporarily deviate from AVM to fix a bug / enable feature Build your own pattern modules but use AVM resource modules
19. Private Modules Library
20. Challenges 1/2 • access management to registry • adding MIs to ACR in ‘vending machine’ • group memberships for engineers • lifecycle management – upstream modules • change feed • all or some • test before publish • publishing cascade
21. • flexibility can lead to complexity and verbosity • e.g., storage-account module (json) has 5281 lines of code • authoring and debugging • template size limits • external dependency - software supply chain Challenges 2/2
22. ADE vs. ALZ
23. References • Private Modules Library • https://github.com/pazdedav/private-modules-library • https://azurescholar.cloud/azure-verified-modules- and-private-modules-a-powerful-combo