In K2, azd brought the Kladde to Azure: azd up read the app host, generated Bicep files in memory, deployed them and delivered the app. That was convenient, but nobody ever saw that infrastructure, reviewed it or ran it through the linter. Since 3.2.1, you've had a second infrastructure of your own in infra/, with modules, linter and stack, just without the app.

In this lesson, you bring both together: azd deploys your Bicep files and delivers the app. To get there, you first look at what azd has been generating out of sight so far.

What azd does

azd reads the file azure.yaml in the root of the repository. For the Kladde, azd init created it in K2 like this:

YAML
# yaml-language-server: $schema=https://raw.githubusercontent.com/Azure/azure-dev/main/schemas/v1.0/azure.yaml.json
name: kladde
services:
  app:
    language: dotnet
    project: ./src/Kladde.AppHost/Kladde.AppHost.csproj
    host: containerapp

There's a single service, the app host. What's inside it, azd learns from the app host itself: It starts it in a special mode in which it doesn't run but describes which resources and projects it has. From that follow the four commands you know from K2:

Command What it does
azd provision deploys the infrastructure: from infra/main.bicep if that file exists, otherwise from Bicep that azd generates in memory
azd deploy builds a container image for each project, pushes it to the container registry and deploys the container app with it
azd up both one after the other, with packaging beforehand
azd down deletes the environment's resource group; --purge also permanently deletes what Azure otherwise keeps in soft delete (a key vault, for example), --force doesn't ask

The first row of the table is the switch for this lesson: If there's an infra/main.bicep in the repository, azd takes that file. But then it also has to provide everything azd deploy needs afterward.