Introduction

This will serve as an introduction to Azure Deployment Environment components. Azure Deployment Environments (ADE) went GA in May 2023. Per the product documentation ADEs is “the service to self-deploy the environments they need on demand using infrastructure-as-code templates”

This sounds awesome and I will cover some of the core concepts that are required to create an ADE such as: Dev Center, Environment Types, Catalogs, and Projects. We will talk more about implementation in follow up posts as this is a rather large topic with endless possibilities.

Components

Before creating an ADE we need to ensure we have all the necessary components created. Now there is some overlap here between ADEs and Microsoft DevBoxes. This is important to recognize that the two products overlap components as the intention of both these products is to enhance the developer experience and velocity. As such they both are key to the newly launched Microsoft developer portal

Here is an overview of the resource structure inside a Dev Center, which one can see overlaps with DevBoxes at the Dev Center and the Project level.

Here is an overview of how the difference components we will talk about relate:

Dev Center

Dev Center is a a resource in Azure that acts as container to house projects. A Dev Center will require a managed identity to interact with other Azure Resources. This is key as the managed identity will be used to authenticate to resources such as Key Vault, which it will require to sync to catalogs.

Network Connection

The Dev Center will require a resource known as an Azure Network Connection (ANC). This resource type is required for the Dev Center to be built and is primarily used for the Dev Box component of the Dev Center.

Network connections allow dev boxes to connect to existing virtual networks. They also determine the region into which dev boxes are deployed.

Configure network connections – Microsoft Dev Box | Microsoft Learn

Managed Identity

The Dev Center will require a managed identity with appropriate permissions. For ADEs it will need to have access to a Key Vault to leverage Catalogs. This will be discussed further when talking about Catalogs.

Additionally the Environment Type will require a User Assigned Identity(UID) for provisioning new resources. This UID’s access for deployment is key to understand as your ADE, when updating resources outside of the ADE’s resource group, will need to have access to make the appropriate updates.

I would recommend having the identity be granted at least Contributor to create resources and User Access Administrator to be able to assign permissions between resources. If wanting to learn more about User and System Assigned Managed Identities be sure to check out my previous post on the topic.

Catalog

The Catalog name is a bit misleading. In this context Catalog is attached to the Dev Center as part of the environment configuration. A Dev Center can contain multiple catalogs and each catalog could contain one or multiple ADE templates.

This catalog will point to a remote repository, GitHub or Azure DevOps, and authenticate to the repository via a Personal Access Token (PAT) that would be stored in an Azure Key Vault and accessed via the Managed Identity associated with the Dev Center.

To assist in getting started the Product Group has created an open source catalog. One question this might arise if the catalog should be a series of templates defined at the Azure Service (App Service, SQL Database, Function App, etc..) or if it should be template containing everything for a project. I’d suggest the lather as this will come in handy when wanting to do certain activities like CI/CD or ephemeral developer environments.

Project

The Project offers a security level inside the Dev Center. The Project will have the ability to provision individual developer access to access the Environment Types defined within the Project. Dev Boxes are also contained in the Project. The Project could be scoped to a specific team and/or product that is being worked on. It will generally depend on how the resource will be administered and/or how the organization does development.

Environment Type

An Environment Type is defined inside a project. The Environment Type will define the Azure subscription and the credentials that will be used for deployment. Not only will it define what the Managed Identity the ADE will use for deploying, but also it will also define what RBAC roles the requester of the environment will be provisioned for and if any additional groups need access.

This is a key concept to understand. The ADE will be creating a new resource group for the deployment and the requester will have RBAC roles scoped to the resource group. This is key for the first scenario of creating a sandbox resource group for a developer to play in. Additionally if working in a team you may include an Azure Active Directory group who may want access to the ADE resources.

One other item of note is that Environment Types will give you the ability to define tags that will be applied to all resources deployed in the ADE.

Conclusion

This was an introduction to Azure Deployment Environment components. Hopefully this article has led to a better understanding of how ADE’s are structured and how their various components interact.