Welcome to Day 29 of #30DaysOfServerless!
We are in the final days of the 30-day journey so it seemed appropriate to end the End-to-End Developer Journey with a discussion on tooling that can simplify and enhance the developer experience from development to deployment and beyond. Say hello to the Azure Developer CLI.
Ready? Let's go!
Today marked the October 22 release of the Azure Developer CLI - bringing with it a few new features and community-targeted resources. Look out for a follow-up post to this one that dives into more details, just in time for #Hacktoberfest! 🌟
What We'll Cover
- A new tool has entered the chat: Azure Developer CLI (
azd) - (Template) Anatomy 101: What makes an
azdtemplate? - End-to-end support: Move code to cloud in a single step!
- Best practices: Monitor your application and run CI/CD on every commit
- Exercise: Try this yourself or create your own
azdtemplate - Resources: For self-study!
A new tool has entered the chat: What is the Azure Developer CLI (azd)?
The Azure Developer CLI (azd) is a new, open source tool that makes it quick and simple for you to move your application from your local development environment to Azure while considering your end-to-end developer workflow. You might be familiar with other CLIs that focus on Infrastructure as Code or scaffolding your application but the Azure Developer CLI does all that and more!
The Azure Developer CLI commands are simple, high-level and map to core stages in your developer workflow. Think project initialization/creation, build, deploy, repeat!
By using idiomatic and flexible application templates, the Azure Developer CLI uses recipes for common application architectures that you can customize for your use case. These templates include:
- best practices
- sample application code that goes beyond "Hello World!"
- infrastructure as code assets so you can move your code to the cloud and set up monitoring for your application, and
- all the bits to set up CI/CD to run on every commit to your repo against resources on Azure
...all in the language(s) you're most comfortable in. You can use an existing template or even create your own (more on that later!).
(Template) Anatomy 101: What makes an azd template?
So now that you've been introduced to the Azure Developer CLI, let's take a look at an azd-enabled codebase, which we call a template. You can think of a template as a recipe - it provides a solid foundation that you can customize depending on your preference/use case/requirements.
To make this concrete and because it's #ServerlessSeptember, we're going to walk through this ToDo application template that uses Azure Static Web Apps and Azure Functions.
Let's talk about the files in terms of their purpose:
Azure Developer CLI-specific files
azure.yaml- contains metadata that describes the application (Azure hosts, languages, template name) and serves as an entrypoint for functionality in Visual Studio Code (oh yeah, you can also useazdusing a VS Code extension!).
Application development support (code, run, debug, test)
.devcontainer/- support for if you're writing code in a container.vscode/- support for local development in Visual Studio Code via launch.json (for debugging) and tasks.json (for spinning up the web app for local development)src/- contains all the sample application code which you can modify or swap out for your own applicationtests/- test for the application, written using Playwright
Infrastructure as Code (provisioning and deploying infrastructure on Azure, programmatically)
infra/- contains all infrastructure as code (IaC) assets written in Bicep or Terraform; includes logic to set up all components we need to set up the application on Azure, wire everything up securely, and monitor application health, performance and usage!
CI/CD
.github/- contains a GitHub Actions workflow to set up a CI/CD pipeline that runs on every new commit to the repo.azdo/- contains a Azure Pipelines workflow to set up a CI/CD pipeline that runs on every new commit to the repo
End-to-end support: Move code to cloud in a single step!
If you want to follow along in this section and don't already have the Azure Developer CLI installed, check out these instructions to install it on Windows, Linux or MacOS in your favorite terminal!
So now that we've gone over what this template contains on GitHub, let's pull this template code down to our local machine, set it up for local development, provision the right infrastructure, and deploy the code on Azure in a single step.
When designing the CLI, we wanted the experience to be both flexible and non-magical (no side effects, easy to understand). So, we're going to run this all with azd up but you could alternatively run a series of three commands and the outcome would be the same - azd init --t Azure-Samples/todo-python-mongo-swa-func (to pull the code down to your machine), azd provision (to provision infrastructure) and then azd deploy (to deploy application code on Azure). Choose your own adventure!
So let's walk through it. On running azd up -t todo-python-mongo-swa-func, I'm prompted for a couple pieces of information as part of the azd init process being run under the hood:
- An environment name - the prefix for the resource group that will be created to hold all Azure resources
- An Azure region - the Azure location where your resources will be deployed
- An Azure subscription - the Azure subscription where your resources will be deployed
Once that information is provided, azd will pull down the code from GitHub and create a .azure/ directory in the project root that contains all Azure Developer CLI environment information that you just entered. This directory will be important when it comes time to provision and deploy infrastructure in the next step in the up process.
The next step here is provisioning. azd is running azd provision on your behalf and leveraging the IaC assets in the .infra/ directory in the project. As the tool works to provision, you'll see an output of each resource (name alongside a unique identifier which you can use to reference back to the Azure Portal, if you want)
Finally, the final step here in running azd up is deployment. azd is running azd deploy and deploying the application code to the resources that we're provisioned in the previous phase of the process. Once this has completed, you'll be able to click on two different endpoint URLs - one for the backend and one for the frontend.
The backend endpoint (service api) hosts the specification for the API via the openapi.yaml file that's also in the root of the project template. You can explore the endpoints that are available in the web app here.
The frontend endpoint (service web) hosts a fully-fledged and functional ToDo web app with a UI, Cosmos DB for the database and Key Vault for application secrets. This isn't just application hosting. It's really everything you need to be successful and productive, all set up on your behalf by the Azure Developer CLI.
...and that's it! We've successfully deployed our application on Azure!
But there's more!
Best practices: Monitoring and CI/CD!
In my opinion, it's not enough to just set up the application on Azure! I want to know that my web app is performant and serving my users reliably! I also want to make sure that I'm not inadvertently breaking my application as I continue to make changes to it. Thankfully, the Azure Developer CLI also handles all of this via two additional commands - azd monitor and azd pipeline config.
Application Monitoring
When we provisioned all of our infrastructure, we also set up application monitoring via a Bicep file in our .infra/ directory that spec'd out an Application Insights dashboard. By running azd monitor we can see the dashboard with live metrics that was configured for the application.
We can also navigate to the Application Dashboard by clicking on the resource group name, where you can set a specific refresh rate for the dashboard, and see usage, reliability, and performance metrics over time.
I don't know about everyone else but I have spent a ton of time building out similar dashboards. It can be super time-consuming to write all the queries and create the visualizations so this feels like a real time saver.
CI/CD
Finally let's talk about setting up CI/CD! This might be my favorite azd feature. As I mentioned before, the Azure Developer CLI has a command, azd pipeline config, which uses the files in the .github/ directory to set up a GitHub Action. More than that, if there is no upstream repo, the Developer CLI will actually help you create one. But what does this mean exactly? Because our GitHub Action is using the same commands you'd run in the CLI under the hood, we're actually going to have CI/CD set up to run on every commit into the repo, against real Azure resources. What a sweet collaboration feature!
That's it! We've gone end-to-end with the Azure Developer CLI - initialized a project, provisioned the resources on Azure, deployed our code on Azure, set up monitoring logs and dashboards, and set up a CI/CD pipeline with GitHub Actions to run on every commit into the repo (on real Azure resources!).
Exercise: Try it yourself or create your own template!
As an exercise, try out the workflow above with any template on GitHub!
Or, try turning your own project into an Azure Developer CLI-enabled template by following this guidance. If you create your own template, don't forget to tag the repo with the azd-templates topic on GitHub to help others find it (unfamiliar with GitHub topics? Learn how to add topics to your repo)! We'd also love to chat with you about your experience creating an azd template - if you're open to providing feedback around this, please fill out this form!