Azure Developer CLI (azd) – August 2023 Release

Savannah Ostrowski

We’re pleased to announce that the August 2023 release (version 1.2.0) of the Azure Developer CLI (azd) is now available. As always, you can learn about how to get started with the Azure Developer CLI by visiting our official documentation.

Here’s what’s new in azd:

  • Preview provisioning changes with azd provision --preview (azure-dev#141)
  • Provide a hint to refresh environment metadata with azd env refresh --hint (azure-dev#2537)
  • azd Azure Pipelines task is now in the marketplace (azure-dev#2536)
  • Azure Developer CLI support in Cloud Shell (azure-dev#472)
  • Promotion of Azure Spring Apps support from Alpha to Beta (azure-dev#2503)

We also have some breaking changes for our Azure Kubernetes Service support this release:

We have also recently published a Learn path with three modules that can help you learn about azd, how to deploy and configure a template, and build your own template. We encourage you to check it out!

Preview provisioning changes with azd provision --preview

As you make changes to your infrastructure as code, you may want to preview the changes before actually provisioning. Prior to version 1.2.0, there was no azd gesture for previewing these changes, which provided a suboptimal user experience as it meant that you might have to provision infrastructure changes that you weren’t sure about.

As of version 1.2.0, the azd provision command now has a --preview flag that allows you to preview the result of Bicep or Terraform changes before they’re applied to your environment. Here are some examples of the experience of --preview when run on Bicep-based templates:

Preview changes with azd provision --preview on a fresh environment

Previewing changes with `azd provision --preview` on a fresh environment

Preview changes with azd provision --preview on an existing environment (after initial azd provision)

Previewing changes with `azd provision --preview` on an existing environment (after initial `azd provision`)

For Terraform-based templates, the same Terraform output you’re used to seeing when running terraform plan is shown.

Provide a hint to refresh environment metadata with azd env refresh --hint

We’ve also introduced a new --hint flag that allows you to provide a hint to azd env refresh about what metadata to refresh. This flag is useful in cases where you’ve made changes to your environment outside of azd or maybe you’re switching machines and want to refresh your environment metadata. With --hint, the string passed in is fuzzy-matched to a deployment name upstream on Azure. If a match is found, the environment metadata is refreshed. If multiple matches are found, you’re prompted to select the correct deployment.

 

azd Azure Pipelines task is now in the marketplace

Last release, we announced that we’d published an azd GitHub Action to the official marketplace. We’re excited to announce that as of this release we have also published an azd Azure Pipelines task to the official marketplace as well to help simplify your CI/CD pipelines.

You can find the azd Azure Pipelines task in the official marketplace.

Azure Developer CLI support in Cloud Shell

Today, we’re excited to announce that the Azure Developer CLI is now available in Azure Cloud Shell. This new support means that you can now use the Azure Developer CLI from anywhere you can access Azure Cloud Shell, including the Azure portal! To get started, open Azure Cloud Shell and run azd commands as you would normally.

Azure Developer CLI azd up in Cloud Shell

Known limitations

Because Docker daemon is unavailable in Cloud Shell, you can’t use the azd commands that require Docker. This limitation largely applies to templates targeting Azure Container Apps and Azure Kubernetes Service. The solution here would be to use a different environment for commands that require Docker, such as your local machine or a GitHub Codespace. For more information, check out our docs.

Promotion of Azure Spring Apps support from alpha to beta

Back in May, we announced support for Azure Spring Apps in Alpha. Since then, we’ve seen many users try out Azure Spring Apps support and provide feedback on the experience. Today, we’re excited to announce that Azure Spring Apps support has advanced to Beta and is available to all users by default. You no longer need to enable Azure Spring Apps as a feature before use.

If you have any feedback or suggestions as we work to get the feature to stable, let us know by filing an issue in the Azure Developer CLI repository. You can also learn more about the Azure Developer CLI’s feature versioning and release strategy on our docs.

Breaking changes for Azure Kubernetes Service support

In version 1.2.0, we have a couple breaking changes for our Azure Kubernetes Service (AKS) support. These changes stem from a bug filed around azd not being able to properly handle formatted configmaps (azure-dev#2367). To fix this issue, we’ve added optional support for text templating in Kubernetes manifests and removed automatic secret creation. These changes are necessary to improve the user experience and to make the feature more stable. If you’re using AKS support, read the following sections carefully.

Adds optional support for text templating in Kubernetes manifests

Before version 1.2.0, azd would perform simple environment substitution on all *.yaml manifest files. This behavior could have unintended consequences and cause runtime errors when variables aren’t available within the Azure Developer CLI environment.

With this change, developers must now opt in by renaming there manifests to *.tmpl.yaml and have access to Go text templating within their manifests. For more information, see azure-dev#2455.

This change is a step toward eventually supporting a fully featured templating and packaging system like Helm, since the syntax is the same. This change also allows for more flexibility in the future to support other templating systems like Kustomize.

Remove automatic secret creation

The initial AKS implementation for azd created an azd resource in the target Kubernetes namespace with all the azd environment key/value pairs. These values could then be referenced by other resources.

With the change in templating in azure-dev#2455, the new recommended approach would be for applications to create their own configmaps as needed and reference azd secrets via templating. This change brings azd to a more cloud-native state where resources aren’t being created unless they have been explicitly defined. If you still want a configmap that contains all azd resources, the templating system allows ranging over maps, which can be used to achieve the same goal.

If you’re relying on azd‘s automatic secret generation, you now need to manually create any configmaps that their apps/services need. For more information, see azure-dev#2464.

New Templates

Since our last release, we also have some awesome new templates to highlight! As a reminder, these templates were designed to be flexible. You can take these templates, modify or swap out the source code, and get up and running on Azure in just a couple of minutes. Each of these templates includes Infrastructure as Code files that specify and configure all the Azure resources needed for your application to run in the cloud.

Reliable Web App Pattern for Java

The Reliable Web App Pattern for Java reference implementation provides a production-grade web application that uses best practices and gives you concrete examples to build your own reliable web application on Azure.

Reliable Web App Pattern for Java

The reliable web app pattern shows you how to update web apps moving to the cloud. It defines the implementation guidance you need to replatform web apps the right way. The reliable web app pattern focuses on the minimal code changes you need be successful in the cloud. It shows you how to add reliability design patterns to your code and choose managed services so that you can rapidly adopt the cloud.

If you’re interested in checking out the Reliable Web App Pattern for Java, you can find it on GitHub or by visiting Microsoft Docs.

Jumpstart Agora

Last week, the Azure Jumpstart team released Jumpstart Agora – a marketplace of various “cloud to edge” industry scenarios (for example, Internet of Things, AI), designed to provide an end-to-end user experience across many different organizational personas. There’s something for everyone, whether you’re IT, a platform engineer, a developer, or a data architect. You can learn more about the Jumpstart Agora release at Announcing Jumpstart Agora.

If you’re interested in checking out the Jumpstart Agora template, you can find it at the new Jumpstart Agora page.

Jumpstart Agora workflow

Other changes and enhancements

We have also added smaller enhancements and fixed issues requested by users that should improve your experience working with the Azure Developer CLI. Some notable changes include:

  • Smaller features:
    • azd pipeline config can now reuse previous a service principal when available (azure-dev#2521)
  • Bug fixes for azd core
    • azd templates – Docker build cache would prevent installing latest azd version on containers (azure-dev#1776)
    • GHA “dubious ownership” git error (azure-dev#2205)
    • Stop using an all in one image for installing azd in template pipeline definitions (azure-dev#2206)
    • URLs printed on pipeline config are invalid (azure-dev#2512)
    • Pipeline status URL is a 404 (azure-dev#2425)
    • Improve help text and error for azd init: -b can only be used if -t is specified (azure-dev#2053)
    • azd pipeline config creates 24 month secret for AZDO (azure-dev#2384)
    • azd down doesn’t clean up resources after failed deployment (azure-dev#2508)
    • Command azd pipeline config failing due to unauthorized error, even though I’m a contributor to the Azure subscription I’m using (azure-dev#1954)

Community contributions

We’d also like to extend a special thanks to the community contributors of this release:

You can use the Azure Developer CLI from:

0 comments

Discussion is closed.

Feedback usabilla icon