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 initfromazd up - A deeper dive into
azd deployand a newazd packagecommand
- Removing
- 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 deployandazd 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:
- Citus Con – April 18 at 10:30am Pacific Time (virtual; speaker: Pamela Fox)
- PyCon US – April 20 at 1:30pm Mountain Time (in-person; speaker: Savannah Ostrowski)
- PyDay – May 2 at 9:30am Pacific Time (virtual; speaker: speaker: Pamela Fox)
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 featuresazd config set alpha.<feature_name> on– Enable a specific feature (names can be grabbed fromazd config list-alpha)azd config unset alpha.<feature_name> on– Disable a specific feature (names can be grabbed fromazd config list-alpha)azd config set alpha.all on– Enable all alpha featuresazd config unset alpha.all– Disable all alpha featuresazd config list– View your fullazdconfig
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 createandazd infra deleteis hidden fromazd -hwith the intent for removal in a future release. Useazd provisionandazd down, respectively, as these commands are aliases. As a result of this removal,infracreateandinfradeletehooks aren’t available inazure.yaml.--outputflag is hidden for all commands for the time being as our team is looking to solidify our output contracts as we continue to build outazd. No warning messages are emitted if the--outputflag is used.azd loginandazd logoutis hidden fromazd -hwith the intent for removal in a future release. We have introducedazd auth loginandazd auth logout. We’re adding the subcategoryauthto allow for a logical grouping for “auth” or “user”-related commands.--serviceflag will be hidden inazd deployandazd restorewith the intent for removal in a future release. We’d encourage you to useazd deploy <service>andazd restore <service>instead.- The following flags are removed from
azd upas a result of the removal ofazd initfrom 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 deployandazd restoredeploys the current service, when the current working directory is set to a service directory (as defined inazure.yaml).azd deployandazd restoredeploys all services, when the current working directory is set to the root project directory (that is, the directory that containsazure.yaml).- In outside of service and root directories,
azd deployandazd restoredoesn’t attempt a deployment and instead offer suggestions. azd deploy --allcan be used to deploy all services, orazd 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 viaazd up) - Type an environment name, select a region, select a subscription
- Run
azd provision(as a standalone command or viaazd 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; rememberazd initis no longer part ofazd 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 viaazd 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!
- Azure Content Team
- ChatGPT + Enterprise data with Azure OpenAI and Cognitive Search – A sample app for the Retrieval-Augmented Generation pattern running in Azure, using Azure Cognitive Search for retrieval and Azure OpenAI large language models to power ChatGPT-style and Q&A experiences.
- New Dapr samples – PubSub, Bindings, Service Invocation samples in Python, JavaScript and C#.
- pamelafox
- Static Maps API (Function App) – A FastAPI that can generate maps using the py-staticmaps package. Designed for deployment to Azure Functions + Azure CDN, using the Azure Developer CLI and Bicep files.
- Flask Gallery Container App with CDN – An example Flask app for a photo gallery designed to be run inside Docker and deployed to Azure Container Apps with the Azure Developer CLI.
- FastAPI on Azure Functions – A sample to run a FastAPI app on Azure Functions
- Flask Chart API on ACA + CDN – An example Flask app for a chart generator API designed to be run inside Docker and deployed to Azure Container Apps with the Azure Developer CLI.
- Flask Surveys Container App – An example Flask app for public surveys (no user auth) designed to be run inside Docker and deployed to Azure Container Apps with the Azure Developer CLI.
- Flask API on Azure Container Apps – A simple Flask API app that is containerized and designed for development on Azure Container Apps.
- savannahostrowski (that’s me!)
- Jupyter Notebooks Rendered with Mercury on Azure Container Apps – A web application used for hosting, sharing and interacting with Jupyter Notebooks via Mercury, hosted on Azure Container Apps.
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 initfails 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:
- lechnerc77 – Using Terraform sample setup with Node.js version 18.LTS (azure-dev#1716)
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, orCmd+Shift+Xfor 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.
0 comments