Skip to content

Azure Developer CLI from playground to production?

If you are a developer who works with Azure or wants to work with Azure, you might already be aware of the Azure Developer CLI (azd), a "new-ish" command-line tool that simplifies and enhances your Azure development experience. Lets run over some of the basics and some thoughts I have on how to make use of azd in a more "production ready" fashion.

What is the Azure Developer CLI?

The Azure Developer CLI (azd) is a cross-platform command-line tool that helps you create, manage, and deploy Azure resources and applications. It is designed to be easy to use, intuitive, and aims to jump-start your journey from local development into Azure.

Advantages of using Azure Developer CLI:

  • Helps you by organising your entire application codebase with dependencies in a tidy and logical manner using extensible templates with a fixed folder structure.
  • Simplifies building and packaging application code, with features like auto-detection of language or framework
  • Allows you to provision Azure resources in a repeatable and automated way using IaC templates and deploy your application using yaml pipelines.
  • Monitor your deployed Azure resources using Application Insights live metrics, logs etc.
  • Tear down the entire environment with a reliable clean up process to avoid unwanted costs.

MSFT Learn: Introduction to Azure Developer CLI

What does the typical workflow look like using the Azure Developer CLI?

  • Select an Azure Developer CLI template or create a template from your existing application code.
  • Initialise the project with the template by running azd init.
  • Package, provision and deploy the app by running azd up.
  • Continue iterating on your application code and deploying changes as needed by running azd deploy.
  • Update Azure resources by modifying the template's Infrastructure as Code (IaC) and then running azd provision

MSFT Learn: Typical azd workflow

Some considerations

  • Even if we are not going to jump in and use azd right away for all deployments, there are still some key learnings we can take from this into existing development approaches. Some that I can think of are, using a consistent structure for folders and files in repos, defining infrastructure and pipelines as code ,and creating reusable templates with parameters whenever possible to reduce future development effort.
  • Using the Azure Developer CLI does not mitigate the need to think about security in your development cycle. Implement security gates to review the infrastructure and application vulnerabilities and make the necessary updates early in the development process. Security is a moving target and these gates should always remain part of the development cycle.
  • azd templates are not a plug and play approach and we should rather view this as a productive head start to our projects. There is still a need to continuously review the Azure infrastructure deployed from azd templates against the Well Architected Framework pillars of cost, operational excellence, performance, reliability and security during the early stages of development to avoid rework later on when deployments have been made to production environments.

Conclusion

azd is a great addition to the list of powerful tools Azure already has to offer. It provides several features that can help you create, manage, and deploy Azure applications faster, easier and in a more repeatable manner. Let's keep in mind that many times the design decisions we make early in the development of a project can lead us to either unbearable technical debt, or it can lead us to an awesome environment everyone wants to build on. Remember to include security and other architecture best-practices early in your development cycle to keep you on the right track.