Accelerate Governance with Deployment Environments

I am super excited to explore and learn this new Azure capability: Azure Deployment Environment.   Azure Deployment Environments empowers development teams to quickly and easily spin-up app infrastructure with project-based templates that establish consistency and best practices while maximizing security, compliance, and cost efficiency. This on-demand access to secure environments accelerates the different stages of the software development lifecycle in a compliant and cost-efficient manner.

Background

Governance of cloud estates is challenging for businesses. It’s crucial to enforce security policies, workload redundancies, uniformity (such as naming conventions), simplify deployments with packaged artifacts (i.e., ARM templates), Azure role-based access control (Azure RBAC) across the enterprise. Often companies address this problem domain by having a platform team that curates set of Infrastructure-as-code modules (e.g., Terraform modules, or ARM template specs) that are authored conforming the organization’s security standards and policies. Then workload teams or product teams can consume them.

Azure offers native capabilities like Azure Policy, Blueprints and Management groups to address this problem. But there are wide range of external solutions (Terraform, Pulumi etc.) available too.

New perspective

Azure Deployment environment brings a more developer-oriented approach to this problem. Let’s explore how this works.

We would need a virtual network, so later we can provision Microsoft DevBox for developers/engineers. Once we have the virtual network, we can create network connections for Dev center.

resource networkconnection 'Microsoft.DevCenter/networkconnections@2022-09-01-preview' = {
  name: networkconnection_ name
  location: location
  tags: {
    Production: 'NO'
    Purpose: 'Demo'
  }
  properties: {
    domainJoinType: 'AzureADJoin'
    subnetId: <Subnet ID>
    networkingResourceGroupName: 'Connection resource group name'
  }
}

This will give us a network connection resource that is connected to the VNET of our choice.

We would also need a key vault where we can store the PAT token for GitHub or Azure DevOps – where we will store the curated ARM templates or Bicep files. The DevCenter will pick up the PAT tokens from the key vault. Therefore, the Managed Identity of the Dev Center needs to have access to read secrets from the Key vault, let’s do that:

resource keyVault 'Microsoft.KeyVault/vaults@2022-07-01' = {
  name: keyVaultName
  location: location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: devCenter.identity.tenantId
    accessPolicies: [
      {
        tenantId: devCenter.identity.tenantId
        objectId: devCenter.identity.principalId
        permissions: {
          secrets: [
            'Get'
            'List'           
          ]
        }
      }
    ]
    enabledForDeployment: false
    enabledForDiskEncryption: false
    enabledForTemplateDeployment: false
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enableRbacAuthorization: false
    publicNetworkAccess: 'Enabled'
  }
}

With the pre-requisites like Network connections to VNET and Key vault are ready, we can now start creating a Dev Center in Azure using the following Bicep module:

resource devCenter 'Microsoft.DevCenter/devcenters@2022-09-01-preview' = {
  name: devCenterName
  location: location
  tags: {
    Production: 'NO'
    Purpose: 'Demo'
  }
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
  }
}

We should see a new Dev Center resource in Azure Portal:

Creating Environment

Here comes the interesting part, in Dev center we can now define the notion “Environment” natively, which often we had to implement by “tags” or some other way. Azure Deployment Environment made this notion first class entity. Let’s see a few examples by defining few “environment types”:

resource env_Acceptance 'Microsoft.DevCenter/devcenters/environmentTypes@2022-09-01-preview' = {
  parent: devCenter
  name: 'Acceptance'
  tags: {
    Production: 'NO'
    Purpose: 'Acceptance'
  }
  properties: {
  }
}

resource env_Production 'Microsoft.DevCenter/devcenters/environmentTypes@2022-09-01-preview' = {
  parent: devCenter
  name: 'Production'
  tags: {
    Production: 'YES'
    Purpose: 'ProductionWorkload'
  }
  properties: {
  }
}

This gives us the environment types in Dev Center.

Creating Catalog

Next entity we will define is a concept of Catalog, we can create catalog – which is basically a git repository (can be GitHub or Azure DevOps) that contains the curated Infrastructure as code templates (ARM templates or biceps). I have created the following GitHub repository (following the sample from Microsoft Learn), this repository contains many curated templates, and each folder must contain a manifest.yaml file, here’s an example:

name: WebApp
version: 1.0.0
summary: Azure PaaS stack with App service
description: Deploys an Azure Web App 
runner: ARM
templatePath: azuredeploy.json

We need to link this repository into the Dev Center, and here’s the Bicep code that does that. Remember to create a PAT token for your GitHub repo and configure that PAT into the Key vault we created earlier.

resource funcAppCatalog 'Microsoft.DevCenter/devcenters/catalogs@2022-09-01-preview' = {
  parent: devCenter
  name: 'Xeniel-FunctionApp'
  properties: {
    gitHub: {
      uri: 'https://github.com/MoimHossain/az-deployment-environment-catalogs.git'
      branch: 'main'
      secretIdentifier: 'https://${keyvaultName}.vault.azure.net/secrets/GITHUBPAT'
      path: 'Environments' // folder in the git repo
    }
  }
}

This gives us a Catalog into the Dev Center:

We can also check the catalog items (the templates in each folder with manifest files in git repository) from Azure CLI:

Creating a Demo Project

Now we can create a “Project” in Dev Center, typically this represents a workload in the company.

resource demoProject 'Microsoft.DevCenter/projects@2022-09-01-preview' = {
  name: project_name
  location: location
  tags: {
    Production: 'NO'
    Purpose: 'Demo'
  }
  properties: {
    devCenterId: devCenter.id
  }
}

Now we can enable the environment types (that we created earlier in Dev Center) into the project:

resource demoProjectEnv_Acceptance 'Microsoft.DevCenter/projects/environmentTypes@2022-09-01-preview' = {
  parent: demoProject
  name: 'Acceptance'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    creatorRoleAssignment: {
      roles: {
        '${ devCenter.identity.principalId}': {
        }
      }
    }
  }
}

Which shows the environment types (we created earlier) shown up in the newly created project:

We need to repeat the process for the Production and Sandbox environment as well. I am skipping that part here.

Creating Environment

Here comes the moment of truth, we will be creating an environment (can be Sandbox, Acceptance or Production- with the project context) using our catalog items (curated templates). Currently we can only do that using Azure CLI

az devcenter dev environment create --catalog-item-name "FunctionApp" --catalog-name "Xeniel-FunctionApp" --environment-type "Sandbox" --dev-center-name "Xeniel-DevCenter" --name "MoimEnv" --project-name "Demo-Project" --user-id "015f84bd-2d24-43d8-a03a-32349d1e2148"

Voila! We can see that the environment is provisioned, using the templates we defined (as platform team) in Catalog repository.

Sure enough, we can navigate to the corresponding resource group and find all the resources provisioned as expected. We can now assign Development Managers (read here) and Developers/Engineers (read here) appropriate roles to these environments.

Dev Box Pool

Icing on the cake, we can also define Dev Box pool in Dev Center, that allows us creating Dev Box (developer workstation in the cloud) instance to work in this project.

Microsoft Dev Box gives you self-service access to high-performance, preconfigured, and ready-to-code cloud-based workstations called dev boxes. You can set up dev boxes with the tools, source code, and pre-built binaries specific to your project, so you can immediately start work. Whether you’re a developer, tester, or QA professional, you can use dev boxes in your day-to-day workflows.

resource projects_Demo_Project_name_DemoProject_DevBoxPool 'Microsoft.DevCenter/projects/pools@2022-09-01-preview' = {
  parent: projects_Demo_Project_name_resource
  name: 'DemoProject-DevBoxPool'
  location: 'westeurope'
  properties: {
    devBoxDefinitionName: 'Xeniel-Workstation'
    networkConnectionName: 'xeniel-vnet-core-connection'
    licenseType: 'Windows_Client'
    localAdministrator: 'Enabled'
  }
}

This creates a DevBox image based on Windows 11.

Which allows engineers to create workspace in the cloud, ready to roll.

Conclusion

It’s relatively new development at this point. I am sure, in coming future when it becomes Generally Available, will open up a great new way to provide governance across large product engineering teams. If CCoE (Cloud Center of Excellence) or Cloud Governance is your area of interest, keep an eye on it!

Thanks for reading.