Azure Developer CLI (azd) – April 2023 Release

Savannah Ostrowski

April 11th, 20230 3

We’re pleased to announce that the April 2023 release (0.8.0-beta.1) of the Azure Developer CLI (azd) is now available. You can learn about how to get started with the Azure Developer CLI by visiting our Dev Hub.

This release includes the following features and improvements:

  • Changes to azd up
    • Removing azd init from azd up
    • A deeper dive into azd deploy and a new azd package command
  • Alpha, beta and stable features (azure-dev#1633)
    • Terraform support in alpha
  • Other command updates
    • Hidden commands and flags
    • Changes to working directory sensitivity in azd deploy and azd restore
    • Changes to your initialization workflow + environments

There isn’t a community call this month but we have many upcoming events where you can learn about the latest in the Azure Developer CLI:

See you all next month! Now, let’s get into what’s new in 0.8.0-beta.1!

Changes to azd up

Since our public preview, we’ve received a lot of feedback around the behavior of azd up being a bit unexpected. Prior to this release, azd up combined both project initialization (a one-time operation) with provisioning infrastructure/deployment (an operation you’re likely to do many times as your build out your app). If you were invoking azd up to get your app up and running on Azure, you would have only benefitted from the azd init step if you ran azd up --template <some_template>. After the initial run of azd up on your codebase, the azd init step would have no-op’d as the application was already initialized with azd. So, azd up was just a provision and deploy in practice.

Removing azd init from azd up

With this release, we’ve addressed this feedback and have removed azd init as a step/sub-command of azd up. With this change, the new flow for getting started is to run:

> azd init --template <some_template>
> azd up

A deeper dive into azd deploy and a new azd package command

Let’s talk more about that last step – azd deploy. This command is really a build lifecycle command/step, which deploys your code on Azure infrastructure. Under the hood, azd packages up your build based on your chosen language’s toolchain and injects all the relevant bits for a successful Azure deployment.

Over the past several months, we’ve received feedback that folks wanted more visibility into this build process. We’ve also heard that there are also some cases where developers want to generate their Infrastructure as Code from another language, rather than writing Bicep or Terraform directly. With both of these feedback themes in mind, we’ve decided to expose a new command – azd package. This new command aims to help you in debugging by providing you with the ability to see exactly what’s being deployed on Azure. As always, we wanted to ensure that azd affords the right level of visibility and flexibility and the introduction of this new command is another step in that direction.

With the 0.8.0-beta.1 release, this new azd package command is now the first step in azd up, followed by azd provision and azd deploy.

We hope that these changes enable you to build applications with whatever workflow makes you most productive. As always, let us know if you have any feedback or questions on the Azure Developer CLI repo.

Alpha, beta and stable features

As we continue to build out the CLI’s capabilities, we want to ensure that our users are clear on the level of fidelity of each feature we add. As you and your teams adopt azd, we want to make sure that you’re set up for success and know which features you can rely on for production and business-critical scenarios.

As such, we’re introducing new alpha, beta, and stable feature stages for the CLI. You can read more about what each of these stages mean and the process for feature graduation on our DevHub. The full list of features and their corresponding stage can be found on our repo.

Practically speaking, you might be wondering what these feature stages mean for you. If you’re using a beta or stable feature, you can continue using them as you are today. It should be noted that you should use beta features with caution in business-critical use cases as there’s a small chance of incompatible changes in subsequent releases leading up to stable. Beta commands are denoted as such with (Beta) in azd -h.

If you’d like to use an alpha stage feature, you now need to manually enable it. Here are some of the relevant commands for setting alpha stage features:

  • azd config list-alpha – List all alpha stage features
  • azd config set alpha.<feature_name> on – Enable a specific feature (names can be grabbed from azd config list-alpha)
  • azd config unset alpha.<feature_name> on – Disable a specific feature (names can be grabbed from azd config list-alpha)
  • azd config set alpha.all on – Enable all alpha features
  • azd config unset alpha.all – Disable all alpha features
  • azd config list – View your full azd config

Terraform support in alpha stage

With this new system, the largest change we’ve introduced this release is that our Terraform support is now behind a feature flag as it’s in alpha stage. We’ve designated Terraform as alpha because we haven’t yet gotten a ton feedback about the current support and its level of fidelity. If you want to use Terraform, you can enable support via:

azd config set alpha.terraform on

We’ll graduate Terraform support to beta stage when we feel like we’ve seen enough usage of it and have received a solid amount of feedback.

Other command updates

In this release, we have also made many updates to core azd commands. Most of the command updates are cosmetic as we wanted to give you all a heads up to the changes we plan to make. If you have any feedback or questions, let us know on the Azure Developer CLI repository.

Hidden commands and flags as of 0.8.0-beta.1

The following commands and flags are hidden from azd -h as of this release. If you’re using the following commands/flags, consider the listed alternatives. If these changes are blocking or break your workflow, let us know by filing an issue on GitHub.

  • azd infra create and azd infra delete is hidden from azd -h with the intent for removal in a future release. Use azd provision and azd down, respectively, as these commands are aliases. As a result of this removal, infracreate and infradelete hooks aren’t available in azure.yaml.
  • --output flag is hidden for all commands for the time being as our team is looking to solidify our output contracts as we continue to build out azd. No warning messages are emitted if the --output flag is used.
  • azd login and azd logout is hidden from azd -h with the intent for removal in a future release. We have introduced azd auth login and azd auth logout. We’re adding the subcategory auth to allow for a logical grouping for “auth” or “user”-related commands.
  • --service flag will be hidden in azd deploy and azd restore with the intent for removal in a future release. We’d encourage you to use azd deploy <service> and azd restore <service> instead.
  • The following flags are removed from azd up as a result of the removal of azd init from that workflow:
    • --template / -t
    • --location / -l
    • --branch / -b
    • --subscription
  • The following flags will be hidden from help text with the intent for removal in a future release:
    • --service
    • --no-progress

Changes to working directory sensitivity in azd deploy and azd restore

As we plan to remove the --service flag from all commands, there are some changes that we’ve made to the current working directory sensitivity of azd deploy and azd restore:

  • azd deploy and azd restore deploys the current service, when the current working directory is set to a service directory (as defined in azure.yaml).
  • azd deploy and azd restore deploys all services, when the current working directory is set to the root project directory (that is, the directory that contains azure.yaml).
  • In outside of service and root directories, azd deploy and azd restore doesn’t attempt a deployment and instead offer suggestions.
  • azd deploy --all can be used to deploy all services, or azd deploy <service> to deploy a given service.

When --all or a specific service name is passed in as the third argument, azd deploy can be run from any directory within your project.

Changes to the initialization workflow + azd environments

To streamline the getting started experience of the CLI, we’ve also been refining azd environments and when they get introduced in your workflow. Prior to the 0.8.0-beta.1 release, the flow looked like:

  • Run azd login
  • Run azd init (as a standalone command or via azd up)
  • Type an environment name, select a region, select a subscription
  • Run azd provision (as a standalone command or via azd up)

As of the 0.8.0-beta.1 release, you aren’t required to run azd login before running azd init. You’re now only asked for an environment name on init and required to select a region and subscription when you run azd provision (either as a standalone command or as part of azd up). The flow now looks like:

  • Run azd init --template <some_template> (as a standalone command; remember azd init is no longer part of azd up)
  • Enter an environment name
  • Run azd auth login (if not already authenticated; credentials are persisted across projects)
  • Run azd provision (as a standalone command or via azd up)
  • Select a region, select a subscription

We believe that this new flow is more understandable as you aren’t required to authenticate on Azure before you provision infrastructure. One other implication that this change has is that commands like azd deploy and azd pipeline config now require you to have run azd provision (as a standalone command or via azd up) beforehand.

New Azure Developer CLI templates

Over the last month, we’ve had some great new templates added to the awesome-azd gallery! A big thank you to the contributors! If you’re interested in learning how to build your own template, check out the latest blog post in our “azd-ify” series!

Other changes and enhancements

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

  • azd init fails after declining to overwrite files from template repo (azure-dev#1656)
  • Error message shouldn’t state ‘bicep’ instead use iac-agnostic term (azure-dev#1521)
  • Service hook: unable to determine script type (azure-dev#1579)
  • Publish templates to azure samples browser (azure-dev#526]
  • Make install scripts install Rosetta 2 if not present on ARM64 (azure-dev#1548)
  • Login flow in Devcontainer fails (improve login debugging) (azure-dev#1609)
  • [AzureDeveloperCliCredential – azd] Wrong token is returned when multi-tenant. (azure-dev#1712)
  • Setting Principal ID on multi-tenant scenario (azure-dev#1729)
  • VS Code: first install errors (azure-dev#1728)

Community contributions

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

Try out these new improvements by installing the Azure Developer CLI!

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 Dev Hub documentation. If you run into any problems or have suggestions, file an issue or start a discussion on Azure Developer CLI repo.

Savannah Ostrowski Senior Product Manager, Azure Developer CLI (azd)

Read next

0 comments

Discussion is closed.

Feedback usabilla icon