The art of simplicity

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III  – Deploying to multiple environments Part IV – Password protect your environments Part V(this post) – Traffic splitting Yesterday I talked about limiting access to your staging environment by password protecting it. This allows you to work with a limited set of test users who can access the staging environment(assuming they got the visitor password). However sometimes you want to do something like a canary deployment where we redirect a small subset of your users in production to a new version of your application. This is something that is also possible in Azure Static Web Apps through the concept of Traffic splitting. To activate this feature go to your Azure static web app resource in the Azure portal: Go to Environments . ...

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III  – Deploying to multiple environments Part IV(this post) – Password protect your environments Yesterday I showed you how you can have multiple environments for your Azure Static Web App. However not every environment is production-ready or should be accessible to everyone. To limit access you can password protect your staging or all environments. To enable this feature, you need to open the Azure Poral and go to your static web app resource. Go to Settings –> Configuration . Switch to the General Settings tab. Change the Password protection setting from Disabled to Protect staging environments only to protect only your app's pre-production environments or Protect both production and staging environments to protect all environm...

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III (this post) – Deploying to multiple environments So far we have deployed our application to one environment, the production environment. Your custom domain points to this environment, and content served from this location is indexed by search engines. However it is possible to use 3 other types of (staging) environments: Pull requests : Pull requests against your production branch deploy to a temporary environment that disappears after the pull request is closed. The URL for this environment includes the PR number as a suffix. For example, if you make your first PR, the preview location looks something like <DEFAULT_HOST_NAME>-1.<LOCATION>.azurestaticapps.net . Branch : You can optionally configure your site to deploy eve...

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II(this post) - Using the Astro Static Site Generator Yesterday I showed you how to deploy your first Static Web App using the VSCode extension. As an example I used a static website created using Astro . What I didn’t mention is that the first time the Github Actions workflow tried to build and deploy the application it failed with the following error message: Build error: Node.js v16.20.2 is not supported by Astro! Please upgrade Node.js to a supported version: ">=18.14.1" The problem is that the Github Action that is created by the extension assumes the use of node 14. As Astro requires a more recent Node.js version the Astro build fails. To resolve this we need to update our package.json to explicitly specify a node version by adding an engines section:

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. In this first post I’ll focus on the Azure Static Web apps extension for VS Code . After installing this extension you can quickly create your Static Web App directly from the VS Code IDE. Open a folder that contains your frontend app in VS Code. Go to the Azure Extension and click on the ‘+’ sign. Choose Create Static Web App from the list of options. Specify a name for the new SWA. Select a region for your staging environments and the Managed Azure Function(if you have one). Now we can choose a preset to configure the default project structure. Azure Static Web Apps will use this information to determine things like the location of our code, build location, etc… In our example we have created a static web site using Astro , a static site generator. As no preset exists for Astro we need to select the Custom option. Now...

As our policy is to keep our .NET applications on the latest LTS version, we started to upgrade our application portfolio to .NET 8. Changing the Target Framework Moniker and updating the ASP.NET Core NuGet packages was sufficient to get the upgrade done.  However the upgrade also triggered some warnings and because we had ‘Treat warnings as errors’ enabled in Visual Studio, our applications refused to compile. SYSLIB0051 The first warning we got was SYSLIB0051 : Severity Code Description Project File Line Suppression State Warning SYSLIB0051 'Exception.Exception(SerializationInfo, StreamingContext)' is obsolete: 'This API supports obsolete formatter-based serialization. It should not be called or extended by application co...

C# record types are designed to be immutable by default. When using a C# record type, you can create a new instance based on an existing instance using the with expression. Behind the scenes the compiler will generate a Clone method that calls a copy constructor: Although a default copy constructor is generated for you, you can create your own if you want to: