Trying out the Azure Developer CLI

We often talk about learning curves when it comes to new technologies and new projects, imagining an initially steep but smooth curve that eventually levels out. In practice of course, it’s more a series of steps, some of which are like cliffs. One of the highest of those steps is standing up target environments and getting code scaffolding in place with the libraries, SDKs, and prerequisites we need.

Each step is a delay—hours or even days when we could be writing code and solving problems. It’s an issue that’s hard enough on our own development devices, but it becomes more complex when we’re working with cloud-native platforms where we’re now responsible for delivering virtual infrastructures and standing up container orchestration. We may not be responsible for infrastructure, but we need to understand both platform and application ops if we’re to deliver modern code quickly and efficiently, especially if we’re handing that code over to operations teams in the future.

We need a way to quickly stand up the tools and services we need to support our development platforms. We need an approach that embodies best practices both in terms of the infrastructure and its security environment. As developers, we’re not trained to think about these things; we rely on operations and security teams to implement these for us. If we could make this process self-service, those expensive resources could be better focused on more than building and deploying development environments; they could concentrate on running and securing live services.

Introducing the Azure Developer CLI

Microsoft recently announced a public preview for a tool designed to do just that, a companion to the familiar Azure CLI that behaves much like the Kubernetes-focused Draft, standing up all the features you need to start coding. Unlike Draft, the Azure Developer CLI goes a lot further, supporting you through the entire software development life cycle with tools that support coding, the build process, deployment, and application monitoring, as well as setting up and running CI/CD (continuous integration and continuous delivery) on Azure DevOps to ensure your code is deployed as it updates.

You even have the option to stand up and run common applications using a single command, with another to remove any deployed resources when they’re no longer needed. As it’s a command-line tool, the Azure Developer CLI will run anywhere you have a terminal, using your developer PC’s terminal, Azure’s cloud shell, or even the terminals built into editors such as Visual Studio Code or in popular IDEs like Visual Studio. There’s no need to learn something different for each environment. The commands remain the same wherever you run them.

Under the hood is a YAML templating language that describes applications and resources, as well as Bicep-based infrastructure as code to configure your Azure environments. Microsoft provides samples initially for common languages such as Python, JavaScript, and C#, along with configurations for common Azure platform services. Java support is planned, hopefully bringing Azure’s Spring tools with it. Microsoft keeps a list of its current templates on GitHub, including building C# code on Azure Cosmos DB or setting up a Dapr microservice in Azure Container Apps.

Currently, the tool supports Azure App Service, Functions, Azure Container Apps, and Azure Static Web Apps, with Azure Kubernetes Service coming soon. It’s not a tool for building out infrastructures beyond Azure’s platform capabilities at this point, though there’s no reason its Bicep support couldn’t be used to deploy complete infrastructures and networking. For now, it’s best thought of as a tool for quickly standing up developer environments that target common Azure features. If you want to do more, you’ll need to add your own resources to any resource groups it creates for you.

Using the Azure Developer CLI

Getting started with the Azure Developer CLI is easy enough. If you’re building modern applications, you should have most of the prerequisites already installed on your development PC. These include up-to-date versions of Git and the GitHub CLI, the Azure CLI, and a Node.js environment including npm. Interestingly, there is also support for Visual Studio Code’s dev containers (a complete development environment in a Docker container, including remote editing and debugging) and for GitHub Codespaces. Support for the recently announced DevBox environments hasn’t yet been announced, but they’re a logical place to host dev containers and could be preconfigured with the Azure Development CLI when used to build Azure apps.

With all the prerequisites in place, install the Azure Developer CLI via PowerShell on Windows or curl on macOS and Linux. It’s important that a tool like this is cross-platform; Microsoft’s strategy is to go where developers are, and supporting all the commonly used development OSes is key to this strategy.

Your first build should be to use one of the prebuilt templates to try the service out using the azd up command to create your target resources. The CLI will prompt you for a name for the Azure resource group that will host your development environment, the Azure location where it will be created, and the Azure subscription used for billing. It’s worth studying the content of these templates as they make a useful tutorial for building your own.

The CLI will stand up the necessary resources, loading and launching any code from a linked GitHub repository. Finally, it will display a list of the resources it has created, along with a link to the relevant content in the Azure Portal. If the code deployed includes endpoints or web UIs, these will all be listed, giving you links ready for application testing. The repository will be cloned to your development environment in the directory where you ran the azd up command. You can then work with the code locally, using git to merge code to the appropriate GitHub branches. To close down services and clean up both your local and Azure environments, use the azd down command.

Build your own application templates

Existing projects can be used to build your own templates. There’s a distinct structure to Azure Developer CLI template files, very reminiscent of the bindle format used by Deis Lab’s WebAssembly. It’ll be interesting to see if it ends up using bindles to work with different development environments where different deployments are needed, especially around resource-constrained edge applications.

Start by setting up a project directory and add any application source code to it. Once that’s in place, the Azure Developer CLI can create an empty template for your code and infrastructure. This contains details of the target environment. You can prepopulate the resulting .env file with details of your Azure subscription and target location to automate deployment. Next, create a new directory called infra, which will contain a configuration file based on the .env file created earlier, along with Bicep files for the various services your application will use, for example, configuring an Azure Container App environment ready for your code containers.

Finally, finish up by creating a YAML file that brings together your project definition files into a single template. You can then take that template and use it in a GitHub Action, using the generated azure-dev.yml file as part of a workflow and deploying changes to your Azure environment as they’re committed to a repository. Use the Azure Developer CLI’s azd pipeline config command to set up an action. Once in place, any local changes committed to GitHub are stored in your repository and then deployed to your Azure environment, ready to test.

Microsoft has done a lot to make the Azure Developer CLI fit into existing toolchains. It’s not perfect, relying on GitHub Actions rather than integrating with Azure DevOps pipelines. However, it’s clearly a work in progress and Microsoft plans to add new features on a relatively rapid cadence, so we can expect to see developer feedback guide the team on what’s needed to quickly deliver cloud-native applications and how it can help move from initial template deployment to live applications: for example, adding support for code generators such as Yeoman and Draft, as well as common frameworks such as ASP.NET or Spring.

This first public preview is certainly a promising start. It’ll be interesting to see if Microsoft can keep up momentum and, at the same time, not get distracted from supporting the heart of the software development life cycle: getting code up and running and ready for production deployments.