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.
- 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.
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
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.
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:
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 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”
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.