Understanding Preview Environments
Part 2 of 3: Azure Static Web Apps – Blazor Web Assembly Front End and C# Azure Functions Backend – Local Development First Method
Azure Static Web Apps is a very flexible and powerful tool on Azure. You can mix and match different frontend frameworks with many different backend frameworks. This series will focus on using C# for both the Frontend and Backend.
Prerequisites:
-
-
- A GitHub Account
- An Azure Account
- Visual Studio 2022 (Community Edition will be just fine)
- Nodejs and NPM installed
-
Part 1 of 3: Setting Up Local Development Environment, Setting Up Client and API Communications, Publishing to GitHub and Azure
Part 2 of 3: Understanding Preview Environments
Part 3 of 3: Authentication and Authorization
Go Directly To The Code: Github
Part 2 – Understanding Preview Environments
In our previous section (Part-2) we discussed setting up our Local Development Environment and deploying our code through GitHub and on to Azure Static Web Apps. Obviously, we are not always deploying to production. So how do we allow people to test our changes before they go live? In this section we will discuss how to do that.
Make Changes to the Application Code
Starting from our project that we created in the previous part the default behavior is to create a preview environment anytime that we do a pull request to the main branch. Let’s explore that.
Remember to start the application by opening a command prompt, changing directories to the place where our application code is and executing “npm start”
Create a branch named “remove_api_url”.
Push Changes to GitHub
Click on the “Push” button.
After it completes you can return to the pull request, and you will notice that it looks like this now.
Browse Environments
We now have a link to our preview environment. Click that link and we should notice that the API URL information is not on the home page anymore.
Complete the Merge
Back in GitHub and in the pull request click on the “Merge pull request” button.
Review Environments
When we look at the Environments tab again in our Azure Static Web Apps resource, we now only see the Production environment.
You will see a notice that your repository has been updated to a specific commit.
Finally, delete your local copy of the “remove_api_url” branch.
Preview Environment Limitations
According to Microsoft the Preview Environments have the following limitations:
- Staged versions of your application are currently accessible publicly by their URL, even if your GitHub repository is private.
- The number of pre-production environments available for each app deployed with Static Web Apps depends on the hosting plan you are using. For example, with the Free tier you can have 3 pre-production environments in addition to the production environment.
- Pre-production environments are not geo-distributed.
- Currently, only GitHub Actions deployments support pre-production environments.
Experiment: All Branches are Preview Branches
If we want all of the branches to be preview branches without having to do a pull request, we can modify our yml build file.
-
1 – In the Visual Studio application click the “Switch between solutions and available views”.
2 – Double click on the “Folder View”
3 – Browse through the .github folder and the workflows folder and then open the yml file.
4 – Update line 6 from master to ‘**’. Furthermore add a production_branch key to the builddeploy job with the value of “master”. This is what my yml file looks like right now.
name: Azure Static Web Apps CI/CD
on:
push:
branches:
- '**'
pull_request:
types: [opened, synchronize, reopened, closed]
branches:
- master
jobs:
build_and_deploy_job:
if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
runs-on: ubuntu-latest
name: Build and Deploy Job
steps:
- uses: actions/checkout@v2
with:
submodules: true
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_PROUD_MEADOW_0D38B1F10 }}
repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
action: "upload"
production_branch: "master"
###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
# For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
app_location: "Client" # App source code path
api_location: "Api" # Api source code path - optional
output_location: "wwwroot" # Built app content directory - optional
###### End of Repository/Build Configurations ######
close_pull_request_job:
if: github.event_name == 'pull_request' && github.event.action == 'closed'
runs-on: ubuntu-latest
name: Close Pull Request Job
steps:
- name: Close Pull Request
id: closepullrequest
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_PROUD_MEADOW_0D38B1F10 }}
action: "close"
Now return to GitHub and check on the actions. You will see that it is building this branch and environment.
You will now see that you have a link like this:
After the pull request has been created your environments will look like this
In GitHub and on the Actions tab you will see that it is working on deleting and merge your branches.
Experiment: Only certain branches are Preview Environments
According to Microsoft: ” You can configure your site to deploy every change made to branches that aren’t a production branch. This preview deployment is published at a stable URL that includes the branch name. For example, if the branch is named dev, then the environment is available at a location like
The advantage to having named branches is that you will always know what URL will be associated with which branch. Earlier when we were doing pull requests, we didn’t know the URL until a Pull Request was submitted. When we were doing all branches, we didn’t know what the URL would be until we pushed our branch. In this place we will know what the URL is once a commit has been pushed to a specific branch in a predictable manner. This will be especially important when dealing with 3rd party identity providers and registering our application with them.
-
1 – Switch back to the master branch in Visual Studio and pull the changes.
2 – Delete your local copy of the preview_branches branch.
3 – Create a new branch called named_branches
4 – Update your yml file such that the push branches have names in the array like so
name: Azure Static Web Apps CI/CD
on:
push:
branches:
- master
- dev
- stage
pull_request:
types: [opened, synchronize, reopened, closed]
branches:
- master
jobs:
build_and_deploy_job:
if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
runs-on: ubuntu-latest
name: Build and Deploy Job
steps:
- uses: actions/checkout@v2
with:
submodules: true
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_PROUD_MEADOW_0D38B1F10 }}
repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
action: "upload"
production_branch: "master"
###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
# For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
app_location: "Client" # App source code path
api_location: "Api" # Api source code path - optional
output_location: "wwwroot" # Built app content directory - optional
###### End of Repository/Build Configurations ######
close_pull_request_job:
if: github.event_name == 'pull_request' && github.event.action == 'closed'
runs-on: ubuntu-latest
name: Close Pull Request Job
steps:
- name: Close Pull Request
id: closepullrequest
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_PROUD_MEADOW_0D38B1F10 }}
action: "close"
-
5 – Commit and push the changes in Visual Studio, then create a pull request and merge the changes in to master using the github website.
6 – Delete the named_branches branch from github.
7 – Review the actions tab of github and wait for all the workflows to run.
Browse to the Github.com website and browse to the repository that has the code for your static web app.
Click the master branch drop down and then in the find or create a branch space type in dev and then click on Create branch dev from master.
Conclusion
Preview environments are a very useful feature of Azure Static Web Apps. In other environments you might have one App Service for the Client Dev, and yet another App Service for the Server Dev, and ditto for Staging and Production. With this set up you can have all this happening within one repository and one Azure resource as opposed to six or more Azure resources. Having branched environments will also make it easier to configure authentication providers. Where we last left off with only certain branches are Preview Branches, it will now only build an environment any time the dev, stage, or master branches are updated. We have a few options here. We could update our YAML file such that pull requests branches match exactly the push branches. We could put ‘**’ for either the push or pull request branches or any number of combinations of things that will work for your workflow. What triggers these builds will be up to you and your workflow, and are all configurable in the workflow YAML file.
About Black Slate
Black Slate is a Software Development Consulting Firm that provides single and multiple turnkey software development teams, available on your schedule and configured to achieve success as defined by your requirements independently or in co-development with your team. Black Slate teams combine proven full-stack, DevOps, Agile-experienced lead consultants with Delivery Management, User Experience, Software Development, and QA experts in Business Process Automation (BPA), Microservices, Client- and Server-Side Web Frameworks of multiple technologies, Custom Portal and Dashboard development, Cloud Integration and Migration (Azure and AWS), and so much more. Each Black Slate employee leads with the soft skills necessary to explain complex concepts to stakeholders and team members alike and makes your business more efficient, your data more valuable, and your team better. In addition, Black Slate is a trusted partner of more than 4000 satisfied customers and has a 99.70% “would recommend” rating.
