Chapter 8 Microsoft Azure

<MSDeployServiceURL>apressdotnetsix.scm.azurewebsites.net:443

</MSDeployServiceURL>

<DeployIisAppPath>ApressDotNetSix</DeployIisAppPath> <RemoteSitePhysicalPath /> <SkipExtraFilesOnServer>True</SkipExtraFilesOnServer> <MSDeployPublishMethod>WMSVC</MSDeployPublishMethod> <EnableMSDeployBackup>True</EnableMSDeployBackup> <EnableMsDeployAppOffline>True</EnableMsDeployAppOffline> <UserName>$ApressDotNetSix</UserName> <_SavePWD>True</_SavePWD> <_DestinationType>AzureWebSite</_DestinationType>

</PropertyGroup>

</Project>

Very different files that serve the same function. The reason these are different is that the publishing profile from the Azure portal is catered especially to cloud deployments, while the version from Visual Studio is more generic and can do deploys to other endpoints like the Windows filesystem, Docker, or any IIS server, for example.

Azure Web Apps or App Service is a great resource for publishing web-based applications. But there might be a better option if your application is pure HTML, CSS, and JavaScript based.

Static Web Apps

Static apps are becoming more and more the norm on frontend web development. Frameworks like Angular, Vue, React, and Blazor all generate client-side logic, relying heavily on RESTful APIs for the heavy lifting and data access. Since everything is executed client-side, we need a way to get the application on the client. In case of JavaScript-based frameworks like Angular, React, and Vue, those are all HTML, CSS, and JavaScript files, something a browser on the client can work with. In case of Blazor, this will be HTML, CSS, JavaScript, and DLL files, something browsers that support WebAssembly can work with. For more information on Blazor, see the Blazor chapter in this book. To get those files onto the client, we need a webserver that serves those files. This is where static web apps on Azure can help. Static web apps are a cloud service that serves files. Static apps can distribute the assets globally so that your application is in the Azure region closest to your customers for minimal delay.

234

Chapter 8 Microsoft Azure

Setting up a static web app is very similar to setting up a default web app. The first step in the creation of wizard should look familiar with a few specific fields.

Figure 8-12.  Creating a static web app

First static web app-specific field is the hosting plan. Static web apps provide a free version for personal projects and a standard plan for professional projects.

235

Chapter 8 Microsoft Azure

Second part is the deployment details. Unlike Azure Web Apps, there is no support for publishing profiles in static apps. Static apps work solely with CI/CD integration, meaning that we need to link our Azure resource to a source repository. The wizard in the portal has a very good GitHub integration as you can see in Figure 8-12. There is support for any source repository, but it will need to be configured from the build server itself instead of here on the Azure portal. For this demo, I have created a default Blazor WebAssembly project.

After creating the resource, a new YAML file will be pushed to the source repository and a GitHub Action will trigger, building and deploying the Blazor application. When checking GitHub Actions, we should see Figure 8-13.

Figure 8-13.  GitHub Action successfully completed

After successfully compiling and zipping the Blazor output, the zip file is uploaded to Azure. Once uploaded, the static web app service will unzip everything; while that is happening, our GitHub Action will poll the service for completion. Static web apps don’t allow us to choose our own hostname like Azure Web Apps did; instead, it generates

236