# GitHub Actions CI/CD for .NET Aspire Applications

## Метаданные

- **Канал:** Milan Jovanović
- **YouTube:** https://www.youtube.com/watch?v=Hjm-K8454tE
- **Дата:** 19.05.2026
- **Длительность:** 11:28
- **Просмотры:** 2,434

## Описание

Want to master Clean Architecture? Go here: https://dub.sh/clean-architecture
Want to master Modular Monoliths? Go here: https://dub.sh/modular-monolith

Join the .NET Architects Club: https://www.skool.com/mj-tech-community-5418/about
Get the 2026 .NET Developer roadmap here → https://the-dotnet-weekly.ck.page/2026-roadmap

Deploying a .NET Aspire application manually is fine once.

But if you want repeatable deployments, you need a CI/CD pipeline.

In this video, I’ll show you how to create a GitHub Actions pipeline for a .NET Aspire application and deploy it to Azure using the Azure Developer CLI.

We’ll start from an empty GitHub repository, create a new Aspire application, initialize it for Azure with azd, configure GitHub Actions, and deploy the app to Azure Container Apps.

You’ll learn how to:

- Create a new .NET Aspire application
- Initialize Azure deployment with azd init
- Configure GitHub Actions with azd pipeline config
- Use federated managed identity instead of storing Azure secrets
- Provision Azure resources from CI/CD
- Deploy Aspire services to Azure Container Apps
- Verify the deployment using the Aspire dashboard and distributed traces

This is a great starting point for automating .NET Aspire deployments to Azure, and you can extend it with tests, security scanning, or end-to-end checks.

Check out my courses:
https://www.milanjovanovic.tech/courses

Read my Blog here:
https://www.milanjovanovic.tech/blog

Join my weekly .NET newsletter:
https://www.milanjovanovic.tech

Chapters

## Содержание

### [0:00](https://www.youtube.com/watch?v=Hjm-K8454tE) Segment 1 (00:00 - 05:00)

If you're not living under a rock, you probably heard about. NET Aspire. Maybe you even built an application using Aspire and try deploying it to something like Azure. Now, in this video, I want to take this further and implement a CI/CD pipeline for deploying Aspire applications to Azure using GitHub Actions. So, let's dive in. This is going to be our starting point. It's an empty repository on my GitHub profile and after we're done with this video, you'll be able to grab all of the source code from the repo if you want to take give it a try. Now, the first thing we're going to do is clone this repo onto my local system. So, I'm going to say get clone, drop the get repo, and now we've got it locally and I'm going to move into the Aspire CI folder. From here, I want to create a new Aspire application and I'll be using the Aspire CLI for this. The command is Aspire new and let me choose the starter app using ASP. NET Core and Blazer. I'm prompted to give this a name. Let's call it Aspire CI demo, for example. We have to give this an output path. I'm just going to use the root directory for this. I don't want to use dev localhost URLs and Redis just to keep this simple. I also don't want to create a test project and after I've jumped through all the prompts, the CLI is going to start scaffolding my application and now we should have it available inside of our directory. One more thing I'm going to do is say dotnet sln migrate if I could type. So, let's try this again and now I've got an sln x file. So, I'm going to start this up in Visual Studio. And this is our default Aspire starter application. I'm going to immediately run it. This is going to start my Aspire app host and while that's starting up, let me show you what's actually inside of our app host. So, we've only got a reference to our API project, our UI application with Blazer and this is what Aspire is orchestrating. When the application starts up, it's going to open up the Aspire dashboard, where we can see our two resources, and I can, for example, open the UI application, use the counter, use the weather endpoint, which is going to trigger an API call, and we can see this inside of the distributed traces. So, nothing too interesting here. It's just a starter template, but we're going to make it interesting by introducing CICD. Let's go back to the CLI, and I went ahead and made a commit with all of these capital changes that we got from the Aspire CLI. So, what is going to be our next step? Well, if I wanted to deploy this, I could use the Azure developer CLI. The shorthand for this is AZD, and we can do AZD init, AZD up, and AZD deploy to get this application deployed through the CLI. However, we don't want to have to do this work manually every time. We're first going to start with AZD init on this repository. And this is going to initialize our application to run on Azure. Now, I don't recommend logging in to your Azure account through the CLI before running this. You can do this with AZD off login or AZ login, and I've already done this, so I'm going to let AZD scan my current directory, and it's going to detect that this contains an Aspire application, and initialize some sane defaults. We're going to see what it is that gets added in just a moment. Now, we have to give it a unique environment name. So, let's call this the Aspire starter app CI demo, and I'll hit enter. And this is going to create an Azure YAML file and some next steps that we can perform. If I open this up from VS Code, we can see these files here. Here's what's inside of Azure YAML, and then here are the next steps. So, from here, we can run AZD up to provision the infrastructure that's needed to host our application on Azure. This includes things like the Azure container registry, any managed identities, storage accounts, and the final target for running our containers is the Azure container app service. Now, there's a nice section here to configure the CI/CD pipeline, and this is actually where we're going to take this next. Now, I said I'll be using GitHub Actions, which is the default one, but you can also use this with Azure DevOps, and the command you need to run is AZD pipeline config. Now, this is your first time using the Azure developer CLI with Aspire, I do recommend checking out this document as it explains what the Azure YAML file does, what's going to happen when you try to provision the required resources in Azure, and all the other details that could be interesting. But for now, let's scaffold the CI/CD pipeline. So, let me clear this. I'm going to say AZD pipeline config. I'll go ahead and run this, and I'll be prompted to choose which provider I want to use. I'll be using GitHub because I want to run this in GitHub Actions, and now this will start configuring my pipeline. You're going to get asked which Azure subscription you want to use for deploying your application, and I've only got one, so I'll choose that. Then you'll be asked to choose which region you want to use for the deployment. I'll use Germany West Central because it's geographically closer to me. I'm going to let it scaffold the

### [5:00](https://www.youtube.com/watch?v=Hjm-K8454tE&t=300s) Segment 2 (05:00 - 10:00)

Azure dev YAML file, and then we have to choose how we want to authenticate from our CI/CD pipeline to Azure. And I'm going to use federated user managed identity, and because I don't have this managed identity, we're going to get asked to create one. I'm going to choose this option. We also get to choose a region for this managed identity, and note that you can reuse this between multiple pipelines if you want to. I'll say create a new resource group, and let's give our resource group a name, or you can just let it use the default option, which is resource group Aspire CI MSI. Let's use that option, and now it's going to go ahead and create the user managed identity. This is going to complete in a couple of moments, and it's also going to add some variables to our repository that we're going to take a look at in a moment. Now, let's jump into VS Code. We're getting one more prompt if we want to commit and push the local changes to start the configured CI pipeline. I'm going to hit yes on this and let it trigger the actual workflow and we're going to examine the execution a bit later. And while this is running behind the scenes, let's take a look at the generated workflow file. So, here's what it looks like. It's added under the GitHub workflows folder and by default it's going to trigger on every push to your main branch. You can customize this if you want to run it on, let's say, pull requests or some other branches. You can also run it manually using a workflow dispatch. This just gives you a nice button on the GitHub Actions UI where you can trigger your CI/CD pipeline. This part here defines the required permissions for deploying our application from your CI/CD pipeline to Azure using the managed identity. And then we can look at the actual jobs within our pipeline. Now, this is going to run on Ubuntu. We've got some environment variables that we're going to pull from the repository. You'll see what these are when I show you the repo. And then the steps here are first going to check out our code base. It's going to install the Azure Developer CLI. It's going to set up. NET. And I actually want to customize this to only target. NET 10. I'll go ahead and commit this change after we're done reviewing. After that, it's going to log in to Azure using the managed identity that we created. Then it's going to provision our resources using ACD provision and finally deploy our application using ACD deploy. So, basically it's going to do what we were doing within our CLI except it's now in an except it's now done in an automated CI/CD pipeline within GitHub Actions. If we refresh our repository, you can see all of the files are now inside. And if I go into the Actions tab, you can see that our initial action is still running. So, let's actually jump inside. So, you can see it was running the provision step for something like 4 minutes, it seems. And now it is deploying our application to Azure using the Azure developer CLI. And when this completes, we'll be able to access our application live hosted on Azure. Now, while this is running, let's take a look at the Azure portal to see what was actually created for us. If I go into my resource groups on the Azure portal, we can see the resource group for our managed identity. And if we go to settings and federated credentials, we can see the credentials set up for our GitHub repository, which is going to give it access to our main branch and also the pull request permissions. Now, if we go back to the resource groups, there was another one there that I want to show you, and it's the resource group for our Aspire application. So, if you go here, you can see we have a few resources. Here's the Azure container registry where we are going to host the Docker containers for our two applications, the API and the Blazer front end. We have a managed identity for managing the access policies between our services, and we've got a log analytics workspace. And last but not least, there's a container apps environment that is going to act as a private network of sorts for our two container apps, and it's also going to give us things like network isolation, making the container apps private within the container apps environment. And all of this is managed through the Azure developer CLI. Now, if I go back to my build pipeline, in the deploy step, we're going to get some logs here that show us where we can find our applications with an Azure container apps domain. You can notice that our API service here has internal, which means it won't be publicly available. It's only going to be available to other services within the container apps environment. Then we've got our web front end, which is publicly available, which you can figure out because it's missing internal. And if I actually click this link, I'll be able to visit the UI. I'm going to hold on for this for a moment as I want to actually show you the Aspire dashboard that also gets deployed. So, if I click this, we should see the Aspire dashboard open up with our two resources. Now, this may be a bit slow to load for the first time, but let me zoom in. And here, you can see our API service and our web front end. So, if I click here, I'll be able to visit our web front end, which is our Blazer app. Let's invoke Let's open the weather component so that we trigger the API call. And if I go back to the Aspire dashboard and take a look at the

### [10:00](https://www.youtube.com/watch?v=Hjm-K8454tE&t=600s) Segment 3 (10:00 - 11:00)

distributed traces, we should see a trace somewhere in here accessing the weather component. And it's also going to contain a call to our API service, which you can see here. And all of this is functioning within Azure. Now, going back to our repository, I want to actually show you the variables that were set when we configured our pipeline. So, if we go to actions and then variables, you can see the repository variables here. So, these are the client ID, the environment name, the location, the subscription ID, and the Azure tenant ID. So, this just contains the name of our resource group, the region where it gets deployed, and a couple of other things that we're going to use within our CI/CD pipeline. And I think this is a great starting point for building your CI/CD pipeline to deploy your Aspire applications to Azure. Now, I will update this to target the latest versions of these actions, so we've got actions/checkout@v6 and actions/setup-dotnet as the latest one. But nonetheless, this is a great default that you can now customize to introduce more things. Let's say you could add testing, you could add security scanning, you could even run end-to-end tests in here if you wanted to, which is something that you can do with Aspire. And after all of this completes, you're going to deploy your Aspire application to Azure. If you want to learn more about the Azure Container App Service, I have an excellent video here that I think you should watch next. If you enjoyed this video, consider gently tapping the like button. Thanks a lot for watching, and until next time, stay awesome.

---
*Источник: https://ekstraktznaniy.ru/video/51635*