Deploying your web app to Azure in 4 simple steps using Azure DevOps

Microsofts Azure DevOps is a great online CI/CD tool for developers and teams. Some of its most important features are:

• Continuous integration/Continuous deployment
• Test tools
• Version control
• Agile software development
• WIKI

Some of these features are nicely integrated into Visual Studio as well, off course.
In this step-by-step walk-through I’ll show you how you can bring your web application to the Azure cloud in a couple of simple steps, using Visual Studio and Azure DevOps. I will not be covering Azure topics like resource groups, subscriptions and service plans, so if you’re not familiar with those parts, head over to portal.azure.com and have a look around or ask Google to help you out.

1. Create your App Service in Azure

This first step is all about setting up an app service in Azure that will host your website.

Browse to https://portal.azure.com/ and login using your Microsoft account. Then follow these steps:

1. click 'App Services' in the left panel
2. click the blue button 'Create app service' or, if you already have one or more app services running, click the '+Add' button at the top
3. You will have to choose a subscription and a resource group, and specify a host name for your app (yourapp.azurewebsites.net).
4. Then you will need to choose what type of app you want to host, by specifying things like runtime and operating system.

Here is my setup:

Click the button Review and Create at the bottom and then again hit the button Create. Azure will now start to create and deploy your new app service.
Once Azure is done, it will notify you of the deployment and you can browse to the new resource.
Open the URL of your created app service (https://reinder.azurewebsites.net in my example) and check that it actually works:

2. Set up application in DevOps and Visual Studio

This is the part where we are going to create a GIT repository within Azure DevOps and upload our web application code to the cloud.
Browse to https://dev.azure.com/ and login using your Microsoft account. DevOps will load your personal space, then follow these steps:

Create DevOps project

Once your project has been created, click Repos in the menu on the left side and then click the button Clone in Visual Studio:

A Visual Studio instance should be opened (if asked to log in, use the same account as you use for DevOps), and you will be asked to specify where to place the repository on your local machine:

In Visual Studio, open your Team Explorer. There is a small link there to create a new project or solution directly in this repository. Click it and create an ASP.NET Core Web Application, with MVC.

Let Visual Studio do all its magic, grab a coffee, have a break and once it is done, hit F5 to check if your new application actually works locally.
Alternatively, you can off course add an existing .NET solution to your GIT repo as well.

If you’re happy with your app, go to Changes in Team Explorer, enter a commit message and commit all your new files to the repo. Then, go to Sync and hit Push. Your files in the master branch are now being uploaded to DevOps.
You can check this by going into DevOps and choosing Repos > Branches in the main menu; you will see all your master branch with all the added files located in that section and you can just browse through them.

But what if I don’t wanna use ASP.NET Core…?

No problem! Azure DevOps lets you build lots of other type of applications as well: ASP.NET, JAVA, Node.js, Android, etc. You could also just add an empty template as a build step and configure a PowerShell script, command line tool, Grunt task, Docker, Maven, Jenkins, XCode, you name it.

3. Create pipeline

Now that we have all our code in place, it’s time to get our deployment pipelines up & running.
In DevOps, head over to Pipelines. Hit the blue button Create Pipeline and follow the steps to setup a new pipeline. In our case, we need to choose ‘Azure Repos Git’, then choose our newly created project and finally choose ‘ASP.NET Core (.NET Framework)’.
The wizard will create a YAML file for you, and place it directly in the root of the corresponding GIT repo.
This default template will only build our application, but we also want the pipeline to package the site into a zip file so we can publish it to Azure. For this to happen, we need to add another task to the YAML.

In the Tasks pane on the right, search for ‘publish build artifact’ and then choose the ‘Publish build artifacts’ task. This will add the necessary task code to our YAML markup.
All done, now we hit the blue button Save and run at the top right.
DevOps will now start this pipeline to build your project; you will see that a Job is now running and if you click on it, you can follow the progress of the build:

If all goes well, you should end up with all green checkmarks.

My build broke!

If anything happens during your build that’s serious enough to make it fail, you can check the logs of that build to figure out what happened.
If you navigate to a broken build, you will see all the different steps on the left and can click on the one that has a red cross in front. This will open the log for that particular step and you can scroll through it to find the error messages in bold red so you can investigate what went wrong. Sometimes these errors will be easy to fix, like a failing unit test or a missing file but sometimes they can be a little bit harder.

4. Create release definition and deploy!

Now that our application has been build, it’s time to deploy it to our app service in Azure.
In DevOps, go to Repos > Releases and hit the blue button New pipeline (or choose New at the top of your pipelines if you already have pipelines running). Now you can start to define where and how the artifact of your build has to be deployed.
You can start off directly with choosing a template, let’s go for the Azure App Service deployment template. This template will add a task to our pipeline which deploys a build artifact to an app service in Azure.

Click the 1 job, 1 task link in our newly added stage

Next, we need to map our build artifact with this new release build. If you click the 'Add an artifact button on the the left side of our release plan, you get to configure where to fetch the artifact from:

The final step! Deploy the artifact of your build to the app service in the Azure cloud.
Go to Pipelines > Releases and click the newly created pipeline; click the blue button Create a Release.

DevOps will automatically start to deploy to our ‘staging environment’ stage, but in the window above you could choose to set this to ‘manual’. Our latest build is also automatically selected, so all we have to do is to hit the blue button Create.
Once created, browse to this new release to check the status:

You can go directly into the logs of each of the steps by clicking on the ‘staging environment’ box:

Wait until all the tasks are finished and you see only green checkmarks.

Now you can browse to you app service within Azure and see you application in action!

What’s next

• Add unit tests
  If you add unit tests to your .NET project, these should automatically be picked up and run during the build, as that step has already been added to the YAML file
• Add build triggers
  For both the build & the release pipeline, you can set all sorts of triggers for when they should start to run automatically. For instance, you could setup automated builds whenever a commit to the develop branch is done, or trigger the creation of a release pipeline whenever a new build from a particular build pipeline is ready.
• Create DTAP
  In my sample I’ve only added a ‘staging environment’ stage. But you can add more stages off course. You can then set different triggers for these stages and can also make them dependent on each other so that you could for instance publish to acceptance whenever a deployment to test was succesfull.
• Modify build/release names
  In the YAML file, you can specify the format of the name of the build. You could for instance add a revision number and the branch name to every build, which makes it easier to distinguish between builds if you have multiple builds available:
  name: $(date:yyyyMMdd)$(rev:.r)_$(Build.SourceBranchName)
  The same goes for a release definition; once created, you can edit the release and go to ‘Options’:
  

and many more…
Also, have a look at all the possible pipeline tasks and release tasks. I’ve only shown some of the basic tasks that can be performed, but there is so much more that you can do within a DevOps pipeline, like running PowerShell scripts, run Angular CLI commands, copy/move files, modify Azure settings or resources, run Bash scripts, run Docker/Kubernetes commands, FTP actions, run Python scripts, Gulp, NodeJS, NPM, Maven etc etc