We’re pleased to announce that the October 2023 release (version 1.4.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:

• azd provision is now faster when there are no infrastructure changes azure-dev#376
• Support for remote environments azure-dev#2765
• A new azd hooks run command for running and testing your hooks azure-dev#1642
• Updated Awesome-azd template gallery awesome-azd
• Promotion of Terraform support from alpha to beta azure-dev#2035
• Call for Hacktoberfest contributions

azd provision is now faster when there are no infrastructure changes

If you’ve been using the Azure Developer CLI for a while, you may have noticed that sometimes azd provision takes a long time to complete when it may not need to. The wait time was because, prior to version 1.4.0, azd provision would always reprovision regardless of whether the underlying Infrastructure as Code had changed. In other words, if you ran azd provision multiple times in a row without changing your code, you would have to wait for the same deployment to complete multiple times.

As of today’s 1.4.0 release, azd provision now checks the most recent deployment upstream on Azure to see if the state is the same as what’s represented in the Infrastructure as Code that’s been used to provision. If the state is the same, the provision is skipped, leading to a faster azd up. If the state is different, the provision runs as normal. This experience is available for developers using Bicep for Infrastructure as Code (Terraform has its own state configuration). Finally, with this new experience, you should also notice improved performance when running azd up in a CI/CD pipeline as provisioning will be automatically skipped when there are no changes.

If you want to ignore the latest deployment state upstream, you can run azd provision --no-state to force azd to reprovision. You may want to pass the --no-state flag in if you’ve made changes to your infrastructure outside of azd (for example, in the Azure portal) and want to ensure that the values described in your Infrastructure as Code are applied.

Support for remote environments

Prior to version 1.4.0, azd only supported local environments, stored within the .azure/ directory in your project. Today, we’re excited to announce that the Azure Developer CLI now also supports remote environments. With remote environments, you’re able to store your environments in a remote location.

Why would I want to use a remote environment?

Remote state environments allow you to share your environments with your team, and keep them in sync across multiple machines.

How do I use remote environments?

To use remote environments, you need to first configure the remote store. You can configure the remote store either globally in azd‘s config.json file, or for a particular project using the azure.yaml file in your application root directory. If remote state isn’t configured in either of these files, azd defaults to storing environment values and any configuration locally. For the initial release of remote environments, the Azure Developer CLI supports Azure Blob Storage for storage. You can read more on the specifics of configuration in our docs.

How do remote environments change my workflow or experience?

Aside from configuring the remote environment store, you shouldn’t notice any difference in your workflow. The main differences you’ll notice are:

• When you run azd env list, you’ll now see environments from both local and remote stores.
• When you run azd env select and the environment doesn’t exist locally, the remote state is copied to a new local environment.

A new command for running and testing your hooks: azd hooks run

As more developers have started to adopt hooks in their azd workflow, we have heard feedback that it can be difficult to test hooks locally as there was overhead to wait for azd commands to run. As of this release, we’re excited to announce a new command, azd hooks run that strives to make it easier for developers to test and troubleshoot hook scripts.

A concrete example

If you’re having trouble imagining how you might use azd hooks run, here’s one example:

Imagine you’re trying to validate a deployment by running a series of UX smoke tests across application services. You might create a validate hook for each service you want to test (using Playwright for testing, for instance). You then use a postdeploy hook that calls azd hooks run validate, as specified in your azure.yaml. To test these hooks in your inner loop day-to-day, you could run azd hooks run validate at any time without having to wait for a deployment to complete.

Updated Awesome-azd template gallery

Last October, we announced the first version of the Awesome-azd template gallery as a way to showcase open-source template contributions. Since launching the Awesome-azd website, the community has contributed nearly 70 templates to the gallery, and thousands of unique visitors have visited the site. With an increasing number of amazing templates, we wanted to make it easier for you to find the right foundational blueprint for your application on Azure. Today, we’re excited to unveil a new look and feel for the Awesome-azd template gallery. Aside from an updated look and feel, we’ve also added improved template filtering and search capabilities to make it easier to find the right template for your application.

We’ll also be adding some more features in time for the November release, so stay tuned!

Promotion of Terraform support from alpha to beta

When we introduced azd feature stages in April, we announced that we moved Terraform support behind an alpha feature flag to communicate that the feature was still in development. Since then, we’ve seen many users try Terraform support and provide feedback on the experience. Today, we’re excited to announce that Terraform support has advanced to Beta and is available to all users by default. You no longer need to enable Terraform support 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 on the Azure Developer CLI repository. You can also learn more about the Azure Developer CLI’s feature versioning and release strategy on our docs.

Call for Hacktoberfest contributions

The Azure Developer CLI loves open source!

We’re excited to announce that we’re participating in Hacktoberfest 2023! If you’re not familiar with Hacktoberfest, it’s a month-long celebration of open-source software. If you’re interested in contributing to the azd ecosystem, there are a couple places you can get started:

• azure-dev – The core azd repo that hosts our CLI binary and VS Code extension. If you’re interested in contributing to the core CLI, this repo is the place to go.
• awesome-azd – The repo that hosts our Awesome-azd template gallery and template metadata. If you’re interested in contributing a template to the gallery, we’re accepting templates across all languages and frameworks!

Both repos have issues tagged with hacktoberfest but we’re open to helping you contribute on anything of interest. We’re looking forward to seeing your contributions – happy coding!

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 for azd core:
  • azd package now allows users to specify a --output-path parameter to control the output location of file-based packages (azure-dev#2543)
  • Add Azure Pipelines Task (setup-azd) to todo templates (azure-dev#2642)
  • azd config --help doesn’t show help for AZD_CONFIG_DIR (azure-dev#2302)
  • azd init now supports --subscription (azure-dev#2050)
  • azd now honors @allowed locations in Bicep to filter the list of possible deploy locations (azure-dev#2695)
  • ARM64 support is now generally available
• Bug fixes for azd core:
  • Failed to azd package api for todo-java-mongo on Apple Silicon (azure-dev#2693)
  • Bicep installer prefers MUSL variant over glibc (azure-dev#2683)
  • When running azd init, the Starter – Bicep template is unavailable. (azure-dev#2794)
  • panic: unexpected bicep type: ” (azure-dev#2791)

Community contributions

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

• pjirsa – Typo in soft-delete warning message (azure-dev#2718)
• lechnerc77 – Update Node.js to version 18 (azure-dev#2753)

You can use the Azure Developer CLI from:

• Your terminal of choice on Windows, Linux, or macOS.
• Visual Studio Code or GitHub Codespaces by downloading the extension from the Marketplace, or installing it directly from the extension view (Ctrl + Shift + X, or Cmd + Shift + X for macOS) in Visual Studio Code.
• Visual Studio by enabling the preview feature flag. You can learn more about the Azure Developer CLI from our official documentation. If you run into any problems or have suggestions, file an issue or start a discussion in the Azure Developer CLI repository.