One of the things that we have been trying to solve repeatedly is a way to provide self-service mechanisms for developers when it comes to building public cloud services. Where we want to provide developers with a predefined service catalog that contains different packaged services or even a full environment that they can order on-demand.
I’ve spent a lot of time on CMP (Cloud Management Platforms) that tries to solve this by providing a centralized self-service portal across different cloud platforms. Either by using its own automation engine or using existing tooling such as Terraform, Ansible, or other automation tools.
Last year Microsoft started to move in the same direction to provide self-service mechanisms with the new service called Azure DevBox, which you can read more about here –> Getting started with Microsoft DevBox | Marius Sandbu (msandbu.org) this is about providing self-service of VDI machines, now they have taken the next step to provide self-service of other Azure services into a new offering called Azure Deployment Environments.
This new feature allows us to create predefined templates which are stored in Github or Azure DevOps (currently only supported ARM templates but Terraform, Pulimi, and Bicep are on Roadmap) where we can provide these as catalog-items which Developers can “order” through Azure.
The service is an extension of the DevCenter resource in Azure which DevBox uses.
So we need to create a DevCenter instance and a Project trough Azure. The configuration of this can be read here –> Create and configure a dev center – Azure Deployment Environments | Microsoft Learn.
The easiest way to test this is to fork this repository Azure/deployment-environments: Sample infrastructure-as-code templates to get started with Azure Deployment Environments service. (github.com) then create a PAT (Personal Access token) in Github which then is stored in KeyVault to allow DevCenter to authenticate to Github and read the content of the repositories. You will notice that the folders in the Github repo under environments have different manifest.yaml files that need to be present.
Then when you are setting up the connection in Github you can add a connection like this.
Clone URI would be ‘https://github.com/youraccount/deployment-environments.git’, Branch would be Main and folder would be ‘/Environments’
Once you setup the Github connection you can verify that the connection is able to read the content of the repository by using the following command.
az devcenter dev catalog-item list –dev-center –project-name -o table
Once the catalog is in place and the resources are available, you need to give the users that want to provision resources access to the project. To be allowed to provision they need to have
Deployment Environments User role on the Project. This allows them to provision all the resources that are defined in the catalog and against the environment that is configured.
Currently, the user interfaces for the end-users of this service that wants provision service needs to be using Azure CLI. For instance, if I want to provision FunctionApp as an end-user I use the following command
So I see that this is a step in the right direction in terms of providing self-service access with a predefined templates using either DevOps or Github (and hopefully sometime soon, the ability to bring existing templates using Terraform, Pulimi or Bicep) – (and also a web-ui)
NOTE: If you get this message
(BadRequest) The DevCenter is misconfigured. Inform DevCenter owners that the DevCenter identity does not have permission to manage role assignments on the target subscription
Ensure that the Managed Identity has owner rights to the subscription or resource group to be able to deploy the Azure. It needs an owner since it needs to give permissions to other users/groups as part of the deployment.