How to keep around old assets in Azure Static Web Apps on new deployments

Question

I have a react app deployed via azure static web apps, and im using github action for ci/cd.

In the app there are dynamic imports which fail when users have open session during deployment because they try accessing file index.[hash].js and that file no longer exists. There is the option of handling that in react with errorBoundary but i want to much rather support multiple version of the app by adding the functionality that the existing files in the static web app should not get deleted on new deployment. Ho can i do this?

Note: I know it's not officialy supported out of the box but was wondering if there is a work around to get this to work. there is a open issue about this https://github.com/Azure/static-web-apps/issues/448

Thanks in advance!

Answer 1

To maintain old assets in Azure Static Web Apps during new deployments, you can consider the following workaround:

Azure Blob Storage: Use Azure Blob Storage to store your assets. You can upload your build artifacts to Blob Storage and reference them in your app. This way, even after a new deployment, the old assets will remain available. You can automate this process using Azure Pipelines or GitHub Actions.

1. Cache-Control Headers: Set appropriate cache-control headers for your assets. By setting a long max-age, you can ensure that users’ browsers keep a cached version of the asset for a longer period. However, this won’t prevent the issue if the cached version expires or if the user clears their cache. Versioning: Implement a versioning system for your assets. For example, you could have a folder structure based on version numbers and keep multiple versions of your assets. Your application logic would need to handle loading the correct version based on the user’s session. Custom Deployment Script: Create a custom deployment script that copies the current assets to a backup location before the new deployment. After the deployment, the script can restore the assets from the backup location. Service Workers: If you’re using service workers, you can manage asset caching and versioning through them. Service workers can intercept network requests and serve the appropriate version of an asset from the cache. Incremental Deployment: Explore the possibility of incremental deployments, where only changed files are updated, and unchanged files are left as is. This might require custom scripting or tooling to compare file versions before deployment.

Answer 2

@Gershy Menzer I can provide some resources that might help you with using Azure Blob Storage and automating it with GitHub Actions:

1. Microsoft Learn Tutorial: This tutorial on Microsoft Learn guides you on how to use GitHub Actions to deploy a static site to Azure Storage.
2. GitHub Documentation: The official GitHub documentation provides a guide on how to enable GitHub Actions with Azure Blob storage.
3. YouTube Tutorials: There are several YouTube tutorials that might be helpful:
   • This video shows how to get started with GitHub Actions for Azure.
   • This video provides an introduction to Azure Blob Storage.
   • This video is a tutorial on how to build your own resume hosted on Microsoft Azure with Blob Storage, Azure Functions, CosmosDB, and GitHub Actions.
4. GitHub Repository: This GitHub repository contains a markdown file that explains how to use GitHub Actions to deploy a static site to Azure Storage.

Remember, the key is to ensure that your GitHub Actions workflow is correctly set up to upload your build artifacts to Blob Storage. Once this is done, you should be able to reference these assets in your app, and they will remain available even after a new deployment.

Please let me know if you have any further questions that we can assist with.

Note: I used CoPilot to provide some of the links.