Skip to content

1.2 AZD Templates

This section is derived from two resources: the Deploy and configure Azure Developer CLI templates learn module, and the Azure Developer CLI templates overview documentation.

In this section, we answer three questions:

  1. Why should we use Azure Developer CLI templates?
  2. How do these templates work?
  3. What does a template look like?

1. Why use AZD templates?

Developers are used to working with application code. But provisioning resources and deploying applications to the cloud can be a challenging task that often requires the expertise of an IT professional. So how can we streamline the end-to-end development workflow to enable rapid iteration and CI/CD automated workflows for application development?

The AZD template defines the infrastructure requirements using Iac (Infrastructure as Code) files that declare the resource requirements, dependencies and configuration in a way that supports:

  • version control (alongside app codebase)
  • consistent deployment (e.g, across different users)
  • repeatable deployment (for debugging or analysis)

The AZD tool acts on the template, streamlining the process for developers with simple commands that apply best practices at each stage of the development workflow from provisioning to deployment.

2. How do Templates work?

  1. Instantiate a template using azd init to setup the required files for infrastructure and application source, in your local folder.
  2. Authenticate with Azure using azd auth login to connect your local development environment to an active Azure subscription you can target for deployment.
  3. Activate the template with azd up which effectively runs the provision (resources) and deploy (application) commands for you under the hood. These use the infra/ and src/ folders to get the resource and application assets, and the azure.yaml file to understand the relationship between them (app services and dependent resources).

3. What's the Template structure?

The typical template consists of a repository with a file structure as shown below. The "if used" elements can be considered optional. The src/ folder may be created empty - in which case the azd tool will provision the infrastructure and may deploy a placeholder application.

The app developer can then refactor the src/ folder and invoke azd deploy interactively (or commit changes with a CI/CD workflow established) to have app updates pushed to the pre-provisioned infrastructure - with minimal effort.

1
2
3
4
5
6
7
8
9
.azure/          # Azure configurationa and env vars for azd usage
.azdo/           # Azure DevOps pipelines configuration (if used)
.devcontainer/.  # Dev Container "configuration as code" (if used)
.github/         # GitHub Actions workflows configuration (if used)
infra/           # Bicep or Terraform "infrastructure as code" assets
src/             # Deployable app source code (e.g., web/, api/ subfolders)
.gitignore       # Standard .gitignore behaviors (e.g., `.env` secrets safe)
azure.yaml       # Maps app services (e.g., web/ api/) to infra resources 
README.md        # Describes template usage, app architecture, quickstart

To get started, you can build off an existing template and customize it - or you can build a new template from your app code from scratch.

In the next section, we'll deconstruct an existing azd template for an Azure AI Foundry application to understand the component files. Then we'll explore using that to create an azd template and workflow for the RAG Chat app.