If you are building an application or a website today, all the rage is to create your site with Continuous integration/Continuous Delivery (CI/CD) to make life easier. And why wouldn’t you want to do this? It is all about automation, making your life easier and simply getting code from development, testing to production in a faster process.
In todays post we are going to look at using Azure DevOps to deploy code from a source to Azure Static Web Apps. If you are not familiar with Azure Static Web App you should take a moment to read the announcement. Via Microsoft:
Azure Static Web Apps is a turnkey service for these modern full-stack web apps with pre-built and pre-rendered static front-ends, and serverless API backends. Develop with popular front-end frameworks or static site generators, quickly build and test your apps locally, and deploy with a simple check-in. This enables you to focus on your app, while Azure takes care of the deployment and infrastructure.
It’s a web server. A super fast web server! And the great thing about Azure Static Web Apps is you can host anything you want. It just serves up those raw files. If you use a tool like Gatsby to take your React.JS site and generate static files, you can use Azure Static Web Apps to host that site for you – must like the site you are visiting today!
Get Everything Ready
Azure Static Web Apps has a built in process to take your GitHub code and automatically deploy it to production. Today, we are going to store our code in GitHub but I’m going to show how you would use DevOps to deploy instead. Why might you ask? DevOps gives you a bit more flexibility if you want to do anything crazy or stupid along the way. For example, in my use case, I want to change environmental variables from sandbox to staging to production along the deployment cycle. Using DevOps, I can take code directly from GitHub, create a deployment pipeline and add all sorts of release pipelines to the mix.
The first step we need to do is create an Azure Static Web App. It is as easy as you would think. Go to the Azure Portal and search to create a new service.
Find Azure Static Web Apps and click create. On the resulting page, you are going to fill in the vital details. A couple of notes:
- If you have an existing Resource Group you can use it like I have done.
- The name of course has to the unique within the Resource Group
- If you select Standard, you will be charged for it
- There are only 5 regions to select from
- Make sure you select, Other for your deployment source. Again, we could use GitHub but I want to use DevOps for this demo.
Dev Ops
Now we are going to go get our deployment ready. Head over to Azure DevOps and login. If you are new, you will need to create a new organization to store your information. The great news is, their is a great free tier for Azure DevOps.
Start by clicking on New Project
Once you have all the details filled in (make sure to select private if you don’t want the world to see) we are ready. Find your newly created project from the dashboard.
We are going to make a Pipeline first. From the left menu, find Pipelines and then click New Pipeline.
Before we get much further, let’s discuss what our plans are. We are going to have three environments. A sandbox, staging and production. Each of these will have its own website, backend database servers and much more. Our frontend is built in Node.js, Gulp and Express. In this scenario we are not using React but rather a custom framework we have built on top of jQuery, Axios, Bootstrap and Telerik for some UI elements. The backend is 100% hosted behind an Azure API Management. So our end goal is to modify the environment files within Axios so depending on which front-end is being used, it will reference the correct backend servers.
Back to our pipeline. Here we are going to build the Sandbox pipeline. The first screen is going to ask where is our project being hosted. In this case, it is GitHub – select that.
On the next screen it will ask you to select the GitHub repo. When that is complete, you will then get the first option to configure your pipeline. We are going to select Node.js.
This is where it’s going to get a bit strange. In this step, even during the pipeline, we are going to deploy to our Sandbox environment. We will then use the release pipeline for Staging and Production. Your first question is, why not use the Release Pipeline for Azure DevOps to deploy the Sandbox as well? Because at the end of the day we have a bit of a unique deployment process. The dev team will ONLY put in a Pull Request into the main branch if they have verified it has tested OK. We do this by injecting the test and validation folks into the Pull Request. The dev with the testing coordinator will ensure the specific item they are working on passes all tests. Once it does, that test will be added to the full library of tests for the purposes of regression testing. This allows the specific developer and test engineer to get the code published through the Sandbox up to Development. It is different but it works for us.
In our deployment file we are going to do the following:
# Node.js
# Build a general Node.js project with npm.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript
trigger:
- master
pool:
vmImage: ubuntu-latest
steps:
- task: NodeTool@0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm install
npm run build
displayName: 'npm install and deploy'
- task: AzureStaticWebApp@0
inputs:
app_location: '/dist'
api_location: ''
output_location: ''
env:
azure_static_web_apps_api_token: $(DeploymentToken)
A few notes about the above:
- The script looks for a trigger and when it receives it, it will start the steps
- Step 1 is to install Node.Js
- Step 2 is to run npm install and npm run build. In this step, NPM calls GULP to compress, do all the magic it does and then copy the final product to the /dist folder
- Step 3 is to copy the contents of /dist to Azure Static Web App. In it, you will see a DeploymentToken.
Go back to the Azure Portal and to your Sandbox Azure Static Web App. There, click on Manage Deployment Token. Copy it.
Then go back to Azure Dev Ops and click on Variables.
On the resulting page, click New variable
Then create a new variable with the name DeploymentToken and the value pasted from your Deployment Token saved in the Azure Portal. Click the “Keep this value secret”
Go ahead and click OK and Save now. The last step is to click Save and Run.
This will save your YML file to your GitHub Repo and setup everything. This will publish to your main branch and kick off the first task. You can see the job in Azure DevOps and click on it for details.
And if we go back to the Azure Portal, we can find our website randomly assigned name and we should see everything we need!