Tag Archives: VS2017

ARM Templates to Deploy your Resources to Azure

Hey all,
Last week we talked about Continuous Integration and Deployment to Azure. We set up an App Service and deployed a .NET Core application using Visual Studio Team Services (VSTS), Azure and Visual Studio. In this post we’re going to explore deployment of your Azure resources, or infrastructure, using the Azure Resource Manager and ARM Templates. In this post we’re going to use Azure, VSTS and Visual Studio 2017 again. I recommend you read my previous post if you’re not already familiar with Azure and VSTS.

Sample code for this post can be found on my GitHub profile.

ARM Templates

So what’s this Azure Resource Manager template, or ARM template, exactly? Basically, it’s just some JSON that describes the resources, like app services, databases and storage accounts, you want to have in Azure. Azure can process this template and create or update our resources based on the template. This is also called Infrastructure as Code or (IaC). I’m assuming you know what JSON is, so I’m not explaining that here.

ARM templates are declarative, meaning you describe what you want rather than how you want it. In practice this means you’re not writing code to actually create the resources, but simply state which resources you want to have.

ARM Templates in Azure

So let’s have a look at what this looks like. If you go to a resource in Azure, any resource, you should be able to get the ARM template from the left side menu. I still have my imunique Web App from my previous post, so let’s see what that looks like. Just find the “Automation Script” menu item.

On the left side of the panel that opens you can find the different nodes that make up the ARM template.

ARM template nodes
ARM template nodes

As you can see this (generated) template has three input parameters, no variables, and three actual resources. A parameter is an input for the script, a variable is a computed value. For now we’re mostly interested in the resources. We have the ‘serverfarm’, or the hosting plan; the actual web app, imunique; and the host name binding, which makes your web app available on imunique.azurewebsites.net (Azure created this for us).

Here’s a part of the actual JSON template describing (a part of) the web app.

ARM templates in Azure
ARM templates in Azure

So there’s some good news and some bad news. The good news is Azure can create most of most ARM templates for us. The bad news is that they aren’t always of high or even usable quality. Of course we can tweak them however we like.

Azure Resource Group Projects

Let’s create our own ARM template. Open up Visual Studio 2017 and create a new “Azure Resource Group” project (found under “Cloud”) and name it whatever you like. I’ve named my solution AzureResourceSamples and the different projects have ARM templates for different resources. Again, you can find it on my GitHub profile.

Once you create the project you can pick a pre-defined template from Visual Studio, like a web app. You can also get a template from the Azure Quickstart templates on GitHub. There’s literally hundreds of them ranging from web apps to VM’s to databases. You can pick an empty template as well, it’s possible to add resources later. I’ve picked the “Web app” from the Visual Studio templates. This creates a web app with a hosting plan, Application Insights and auto-scaling. The ARM template can be found in the WebSite.json file. I can recommend studying it thoroughly.

Azure Resource Group project
Azure Resource Group project

The first thing we can do is right-click the “AutoScaleSettings” in the JSON Outline and delete it. We also don’t really need all those Application Insights alert rules for now, so delete those too. In fact, let’s keep it simple and also delete the “AppInsightsComponent”. We’re left with a very basic template that just creates a hosting plan and a web app. Here’s the “resources” node that has the web app and hosting plan, but not the parameters and variables.

Deployment in Visual Studio

Now let’s deploy them to Azure using Visual Studio. Simply right-click on your project and select “Deploy” and then “New…” from the drop down menu. In the form that pops up you can set your Microsoft account, your Azure subscription, the resource group you want to deploy to and the template parameters (those are stored in the *.parameters.json file). Make sure you fill out your parameter values or the deployment will fail. Now simply hit the “Deploy” button and browse to your Azure portal. If all went right you should now see a new hosting plan and a new web app in the resource group you selected.

If the resource you’re deploying already exists Azure will update that resource so it matches the ARM template. You can set literally every property you can set through the Azure portal in an ARM template as well.

A few notes considering the syntax of ARM Templates: when you need a non-static string (a parameter, variable or the result of a function) you can use the "[...]" syntax. To use a parameter you can use "[parameter('paramName')]" and to use a variable you can use "[variable('varName')]". Another very handy function is concat, which you can use like "[concat('staticstring', variable('nonstatic'))]". Other useful functions are resourceGroup() and subscription(), which can be used to get the current resource group id or location or the subscription id.

Deploy per resource

Since it’s possible to reuse hosting plans you may not want to have to deploy these together. Creating a template with only a hosting plan is easy. Simply create an empty template and add an “App Service Plan (Server Farm)” resource. The result is pretty much what we already had in the previous example, but without the web app.

So let’s create a template that only has a web app. This is a little trickier since both Azure and Visual Studio need a hosting plan with a web app. Ideally, you want to be able to set the hosting plan with your deployment since you’re probably going to have different hosting plans for different environments. Since it’s easier to start with something, simply create a template for a web app with a hosting plan.

Parameters

The first thing we’re going to do is add our own parameters. We want to be able to set the hosting plan, the resource group of the hosting plan (Azure will look in the current resource group by default), and the name of your web app because we don’t want a random name like in the previous example. I’ve given the “hostingPlanName” and “hostingPlanResourceGroup” default values because we’re most likely to use these values (for now).

Variables

The next part is where things get tricky. It’s all pretty straightforward, except for the “serverFarmId” variable, which is the hosting plan. Because the hosting plan can be in a different resource group we have to specify the complete path to the resource, including our subscription ID. While it’s possible to share resources in different subscriptions we really don’t want to go there, so I’m sticking to the current subscription.

Now try to deploy this again to a new resource group, but keep the existing hosting plan from the already existing resource group. You can now deploy this web app to any resource group using any hosting plan in any other resource group (within the same subscription).

Connecting VSTS to Azure Active Directory

Before we go any further we have to do one tiny little thing. Head over to Azure and look for the “Team Services administration”. You should be able to see your VSTS account there. Simply click your account and in the options pane that pops up click the “Connect AAD” button. This will hook up your VSTS users to Azure Active Directory (AAD). We’ll need this when we’re going to set up resource deployments to Azure in VSTS.

VSTS in Azure
VSTS in Azure

If it doesn’t work right away try going to the Azure AD first and create a directory there, then try to connect again.

Continuous Deployment using VSTS

We’re now ready to deploy our ARM templates with our web apps or just as a stand-alone release. Head over to VSTS and create a new project or use an existing one. In your project head over to the releases tab, create a new pipeline and choose for the “Empty process”.

You may want to host the examples in VSTS. I’ve used GitHub and it’s perfectly fine to connect GitHub to VSTS (although it’s not in scope of this post so you’re going to have to figure that one out yourself). It’s really easy to do though, just create a new pipeline, add an artifact and set GitHub as a source type. From there VSTS will guide you through setting up GitHub Authorization for VSTS.

Anyway, create a new release pipeline and set your artifact to the ARM templates repository. You can turn on continuous deployment (using the lightning icon in the upper right corner of your artifact). Rename your environment to “Dev” or whatever you like.

Azure Resource Group Deployment

Now it’s time to add a task. Head over to the “Tasks” page for you Dev environment and add the “Azure Resource Group Deployment” (under “Deploy”). Choose your “Azure subscription” and hit the “Authorize” button. This should work because we’ve set up VSTS in Azure AD. Leave the “Action” at “Create or update resource group”. Then pick the resource group you want to deploy to, you can either pick one from the drop down or type any name you want. Next, you have to pick the location of your resource group so either pick the location of the group you’ve picked or set the location for your new resource group.

The next thing we need to set is the “Template”. This field has a browse button for our convenience so use it and select “WebSite.json” in the “WebApp” folder so VSTS will create or update a web app. Do the same thing for “Template parameters”, but instead pick the “WebSite.parameters.json” file. In the “Override template parameters” field you can override your parameters, which you should do. The “hostingPlanName” and the “hostingPlanResourceName” should have a correct default value, but you may want to change the “webSiteName”.

VSTS release pipeline
VSTS release pipeline

Once you’ve set these you’re good to go! Give your release pipeline a name, save it, and create a new release. If all goes well your web app should be created in your Azure account.

If all goes well you can clone your Dev environment and simply overwrite your parameters (and possibly change your resource group) and create a Test environment.

Wrap up

And that’s it. It really is that easy to automatically deploy your web apps to Azure. And not only that, you can deploy VM’s, databases, queues, storage accounts, and pretty much anything you can think of, using ARM templates. If you turned on continuous deployment your deployment should start automatically when you push a commit to Git. And there’s nothing stopping you from also deploying your actual software or other Azure resources in the same deployment.

Again, don’t forget to remove your resources or you’ll be billed for them.

Happy coding!

Azure Deployment using Visual Studio Team Services (VSTS) and .NET Core

Hey all,
After three years of radio silence I decided to write a new blog post *crowd goes wild*! A lot has happened since my last post. I wrote a book on Continuous Integration, Delivery, and Deployment (with JavaScript and Jenkins, mostly); got a Microsoft Azure certificate; found a new job using those Azure skills; and I got my own company on the side. Three years ago I ended with a blog series on math, but I’m not finishing that. Apologies if you were really looking forward to #4… My new focus, for now, will mainly be Microsoft Azure, Visual Studio Team Services (VSTS), and C# .NET Core. So without further delay, let’s talk about those!

Microsoft Azure

Microsoft Azure has been around for a few years now and you’ve probably heard of it. It’s the Microsoft cloud platform that competes directly with Amazon’s AWS and Google’s Google Cloud. If you don’t really know what “the cloud” is (besides the pretty hyped buzzword) I suggest you really look into it as I believe it’s the future (heck, it’s the present)! If you do not already have an account I suggest you create one. It’s free and you only need a credit card and a Microsoft email account like hotmail or outlook.

Beware, Azure is free for now. You get free credit which is valid for one month. Some services cost a monthly fee, for others you pay per use. Just having an empty Azure account is always free. In this post we’re going to host a default web application in Azure using an App Service (which, in any case, will cost you close to nothing).

Visual Studio Team Services (VSTS)

VSTS is Microsoft’s cloud version of Team Foundation Service (TFS), which is their tool for continuous integration and deployment, source control, and agile tools like SCRUM and Kanban boards. Again, if you do not yet have a subscription I recommend you create one. Just like with Azure it’s free and you need a Microsoft email address, like hotmail or outlook. For the free version of VSTS you get quite a bit of functionality, like 240 free build minutes per month and unlimited free private Git repositories (always use Git, never Team Foundation Service Control (TFSC)). With an MSDN subscription you get some extra functionality, but the free tier is good enough for this post.

.NET Core

Do I really need to explain this? For the last few years Microsoft has focused on .NET Core, an open source multi-platform subset of the .NET Framework. While it still has some issues, even in the latest .NET Core 2.1 release, it’s also pretty cool and I’m already using it for production software. It’s a bit different than the full .NET Framework, but not a lot. You may have to download and install the latest SDK, which can all be found on the .NET Core GitHub page. Visual Studio support for .NET Core starts from Visual Studio 2017, so be sure you’re up to date, otherwise you can probably follow along with a regular .NET Framework ASP.NET Web Application.

Creating a .NET Core project

So let’s put these tools together. We start by creating a new (private) project in VSTS, which is pretty simple. In fact, you probably already created one when you created a VSTS account. I kept the default, MyFirstProject. When you browse to the Code tab of your project in VSTS you can initialize your repository (at the bottom of the page) with a README.md file and a .gitignore file (choose Visual Studio).

Initialize a repository in VSTS
Initialize a repository in VSTS.

You can copy the link or clone directly into Visual Studio on the next page in the right upper corner under the “Clone” button. I’m assuming you know how Git works, so I’m not covering that here.

Once you have the repository locally we can start by adding some code. Since we’re focusing on deploying to Azure using VSTS it doesn’t really matter what code you have, so just create an ASP.NET Core Web Application in Visual Studio 2017. You can pick a regular Web Application (which will use Razor View Pages by default) or a Model-View-Controller project, whichever you fancy. Once the default web application template loads you can commit and push it to your Git repository and we can start the fun!

Azure App Services

For the next step we’re going to mess around in Azure a bit. Log in to your Azure portal and find your App Services. Simply click the “Add” button, pick a “Web App” and hit “Create”. On the next page you can set some settings for your web app, such as the URL at which your app will be hosted (which always ends at .azurewebsites.net).

New Azure Web App
New Azure Web App

You’ll also have to create a resource group or pick an existing one. A resource group is simply a way to group certain resources for a quick overview. For example, you can have a separate resource group for dev, test, acceptance and production or for your customer portal and your internal tools, it’s all up to you.

The most important setting here is the App Service Plan/Location. This is basically a server that you pay for. A new plan is generated for you, but you can create your own as well. You have different price tiers with different hardware specifications and Azure functionality, like CPU, memory, custom domains, staging slots, and daily backups.

The location of your plan determines where the server is physically located. For me, in the Netherlands, West Europe is ideal because I know it’s in Amsterdam. Just go with the default Standard S1 plan. Even if you don’t have free credits you can delete it after you’ve read this blog post and it will only cost you like $0.03, so don’t worry about costs.

Setting up deployment from Azure

For now we’re staying in Azure. You’ve probably seen the “Build and Release” button in VSTS. That’s where you can create new build and deployment pipelines, which is great, but also a bit of work.

A build pipeline can automatically build and test your software after a push to Git. This includes restoring NuGet packages, minifying and bundling any HTML, CSS and JavaScript you might have, executing task runners and basically anything you’d ever need to make your software build and run. When your latest commit is built and tested VSTS can create an artifact for publication.

The deployment pipeline can download the artifact from a build pipeline and put it in Azure (or on your own on-premise servers). The trigger for a deployment is usually that a build has succeeded, but can also be a push to Git or a manual trigger.

When you’re building and testing your software automatically this is called Continuous Integration (or CI) and when your software is also automatically deployed this is called Continuous Deployment (or CD). There’s something in between, which holds off the deployment until a user explicitly presses a button and gives the “okay” sign, this is called Continuous Delivery. When you’re doing both CI and Continuous Delivery and/or Deployment you’re doing “CI/CD”.

Let’s set this up with pretty much a single button click. You’ve got two options in Azure. In your Web App, either configure deployment from the “Deployment options” menu item or use the newer “Deployment Center (Preview)” which, as the name suggests, is still in preview.

Deployment options in Azure
Deployment options in Azure

Deployment options

It’s really so simple I’m not even sure if I should walk you through the next steps. Click the “Deployment options” menu item and simply fill in the options you want to use.

Deployment settings in Azure
Deployment settings in Azure

And that’s that. If you now browse to the Deployment options in your Web App you’ll see that Azure now shows all your commits. If you push a new commit to your repository you can even see the build status in Azure because Azure linked it to your VSTS account.

Continuous deployment in Azure
Continuous deployment in Azure

When deployment is done, browse to your Azure website (for me that’s imunique.azurewebsites.net) and behold, your website is up and running! Try changing something on the homepage, push it to Git, wait a few minutes, and see your website get updated.

Deployment Center (Preview)

My guess is that Microsoft is planning to replace the “Deployment options” with the “Deployment Center (Preview)”. If you have already set up CI/CD with the Deployment options you’ll see your commits in here too. For the purpose of this blog we’re going to “Disconnect” (button in the top menu).

Now go to the Deployment Center (Preview) and you should see various source control options, like VSTS, Github and Bitbucket. It’s a little more visually appealing than most Azure panels. So pick VSTS and continue. Next, you have to pick a build provider. I have zero experience with Kudu, so pick “VSTS Continuous Delivery” (which somehow isn’t the default).

Deployment center in Azure
Deployment center in Azure

In the next panel you can pick your VSTS account and repository. Unfortunately, at the time of writing this blog there seems to be a bug here which prevents me from picking an account. It worked in the past and the Azure team said they have fixed the problem in an upcoming release (which is pretty often)… So try it our yourself as this may work for you!

Anyway, if you continue, Azure creates a build pipeline and a deployment pipeline in VSTS! Now that’s pretty cool. It gives you complete control over your builds and deployments as you can tweak them however you like. At the same time the Deployment Center now shows you which builds have been deployed.

Pipelines in VSTS

So browse to your VSTS and check out the build. The user interface isn’t always intuitive, but you should be able to find it. You can edit the build and click around a bit. You shouldn’t need to change it, but you can.

VSTS build
VSTS build

The deployment is a little different. There’s just one build for every piece of code, but there can be multiple deployments, for example for your entire DTAP street (dev, test, acceptance, and production). Azure created a release with a single environment, “Dev”.

VSTS release
VSTS release

You can change the deployment in the “Tasks” for that environment (either click the Dev tile or select Tasks in the upper menu). The tasks look kind of similar to the VSTS build and can be (completely) different for each environment. Mostly, your tasks will be more or less the same and you’ll only have some values that differ per environment. You can use “Variables” for these different values, but that’s out of the scope of this post.

It’s also pretty easy to clone an entire environment (including it’s tasks and variables). Just hover over the tile of the environment you’d like to clone and a “Clone” button will show up. Click it and you get a new environment that’s exactly like the one you cloned. Further setup of builds and releases is out of scope of this post, but you can click around if you like.

When you’re done playing around simply delete the release and the build pipelines (in that order). Also make sure you disconnect the deployment in the Azure Deployment Center.

Deployment from Visual Studio 2017

Finally, let’s switch back to Visual Studio. You can do the exact same thing in Visual Studio. Right click on the project you want to release (which is your web project) and choose “Overview” in the drop down menu. In the page that opens go to “Publish” (in the menu on the left).

Here you can publish or set up your CI/CD. Click the “Start” button under “Continuous Delivery” and you can once again choose a VSTS subscription and an App Service (it creates a new App Service by default, but you can also select an existing one). Simply clicking the “Ok” button will have the same outcome as what we did in the Deployment Center. It will create a new build and deployment pipeline that is also visible in your Deployment Center. Pretty cool!

Going back to the Publish page in Visual Studio, you can also just publish directly. This is pretty useful if you want to release something to Azure right now. Simply click the “Start” button under “Publish”. You can now either create a new Azure App Service or pick an existing one. Just follow the wizard and your application will be published to Azure directly, without a build or deployment pipeline. Be careful though, your local build will be deployed, which will often be different than a build from the build server.

Wrap up

So there you have it! Deployment was never this easy! In just a couple of minutes we’ve created an application, put it in source control, and deployed it to the cloud, ready for the world to see (you can restrict access, but that’s out of scope). In the past it could take you hours to set up a new server (or days and even weeks if you still had to order one), but this alternative is a lot faster and cheaper.

The next step is using ARM (Azure Resource Management) templates to automatically create App Services and other Azure resources. Check out my post on ARM templates to get started.

Don’t forget to delete your App Service and your App Service plan or you’ll be charged for them!

Good luck and happy coding!