Static Web App
(SWA) is a software as a service (SaaS) solution hosted by Azure cloud which
enables us to use Content Delivery Network (CDN) to host single page
applications (SPA) built with JavaScript frameworks like React, Angular and
others.
In addition
to the provisioning of the SPA, a serverless function endpoint is created as
part of the application. This enables the JavaScript code to call APIs within
the same domain to avoid Cross-Domain problems. The default route used by the
client-side code is set to /api by default.
While this
SASS solution manages the hosting concerns for our apps, we still need to be
able to manage the DevOps concerns for building and deployment of the application.
For that process, we can rely on the use of GitHub Continuous Integration
Continuous Delivery (CICD) pipelines to manage the build and deployment process
of our applications thus making this architecture a fully automated turn-key
solution for any static web application.
What are
we learning?
In this
article, we look at automating the deployment of the Azure resources to create
a SWA using the Azure CLI. This way, we have a repeatable process to deploy
other apps. We also link our SWA with a GitHub branch, so we can create a GitHub
action which builds and deploys our application the moment we merge a pull-request
into the branch.
To follow
along, make sure to have all the requirements available on your workstation.
This includes Azure CLI, Visual Studio Code and a GitHub repository with a
sample project and token. The token is used to access the repository with the
permissions to create the GitHub Action workflow file and API secrets.
https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
To get
started, we need to open our GitHub Repo with Visual Studio Code (VSC). We then
need to open a terminal console right from VSC, so we can enter the CLI
commands. When the terminal is ready, we can type the following command to make
sure that Azure CLI is correctly installed.
az –version
|
Azure CLI
Commands Reference:
https://docs.microsoft.com/en-us/cli/azure/
This command should return the current version of the Azure CLI. If this is not the case, review the Azure CLI installation from the Microsoft website. If the CLI is correctly installed, we can next look at the following Bash script, so we can understand what information we need to provide to create the SWA and link it to the GitHub action.
Note: Bash
script can run from a Linux terminal or Windows using WSL with the Linux
subsystem.
Review
the CLI script
This script
prompts the user for information to execute a series of commands to create the
resources. In general, these are the commands and their purpose:
Command |
Notes |
az
login |
Login
to Azure |
az account show |
Shows the current account for verification |
az
account set |
Sets
the default subscription which host the resource to be created |
az group create |
Creates a resource group with location information
like East/West |
az
staticwebapp create |
Creates
the SWA and GitHub action to automate the deployment after a push is done on
the provided branch |
az staticwebapp appsettings |
Sets configuration settings for the application.
These settings are server-side settings which can be used by the serverless
functions that are created automatically with our SWA |
After
reviewing the code, we can download the gist and run it from Visual Studio
Code. To run the Bash file on a terminal
window, enter the following command:
bash filename |
Follow and enter the information as prompted. Once all the commands are executed, we should do a git pull from the repository branch. The pull downloads the CICD workflow file that was created when the SWA resource was provisioned.
Review
the CICD workflow
Once the git
pull is complete, we should notice in Visual Studio Code explorer that a new
folder (github) and yml file is created. Open the file, so we can review the commands which
the workflow executes to build and deploy our code. From the yml file, we
should see the workflow name, branch name, jobs and build and deploy
configuration. In general, we should change the workflow name to something
meaningful, like the branch or resource name. This name is visible on the GitHub Actions tab, so we want to be able to easily identify what action is associated
with a resource.
On the Build
and Deploy configuration section of the workflow, we want to review three
settings:
Setting |
Notes |
app_location |
This should
be set to the location of the source code. This is usually the root folder.
Change this to match the project location.
|
api_location |
This by default uses the path /api which is the
route use to call the serverless functions. This should also be changed to
match the project configuration.
|
app_artifact_location |
This is
set to the build folder location. In the case of React and Angular projects,
this folder is usually named build. If this is not the case in the current
project, update this to match the project configuration.
If
this information is not correct, the GitHub action fails with a “Unable to
find a default file in the artifact folder”.
The
error is visible in the Actions' area of GitHub. There, we can find all the workflow
executions every time we push code changes into the repository branch.
|
See this
example workflow yml file for more information.
After making changes to the YML file, we can create a PR or push directly the changes to the branch. This should trigger the action, and we should see our changes work and see how the build is deployed to the Azure resources.
Once the build
is complete, open the Azure console and visit the Static Web App resources.
Open the one that was just created and click on the URL, which can be found on
the overview tab. If all is well, the site should load on the browser.
Automation
for all
There are many options to host your SPA, but it is important to be able to automate the build and deployment process, as well as the provisioning of the resources that need to be created on any cloud platform. Azure Static Web Apps with GitHub Actions provide an excellent process to manage the automation of all our DevOps concerns for our Single Page Apps.
Thanks for
reading.