Tag Archives: CI/CD

Azure, CodeProject, Programming, Software Development, Web Development

WebJobs in Azure with .NET Core 2.1

2 Comments

The post “WebJobs in Azure with .NET Core 2.1” appeared first on MSDN Azure Development Community.

WebJobs aren’t new to Azure or .NET. There’s even a default Azure WebJob template in Visual Studio 2017 for the full .NET Framework. However, a similar template for WebJobs in .NET Core is somehow missing from Visual Studio. In this post, I’m using .NET Core 2.1.

Creating a WebJob in .NET Core isn’t hard, but you have to know some tricks, especially if you want to use some .NET Core goodies like logging and DI.

In this post, we’re going to build a WebJob and release it to Azure using Visual Studio, the Azure portal, and VSTS.

You can find the code samples for this post on GitHub.

What are WebJobs

A WebJob is a program running in the background of an App Service. It runs in the same context as your web app at no additional cost. Maybe you need to do some hourly task or do some cleanup task every night at 1 AM. Azure Application Insights uses a WebJob to report your app’s statistics.

WebJobs can be scheduled, like hourly or daily, but they can also be triggered. A trigger could be a file upload or a new message on a queue.

WebJobs vs. Functions

I’ve often found comparisons between WebJobs and Azure Functions. In a way, Functions are the successors to WebJobs. Functions are (usually) small pieces of code that run in Azure and are, just like WebJobs, triggered at a certain event, including an HTTP trigger.

Functions are often a great alternative to WebJobs, but if you already have a web app it could make sense to use a WebJob instead. Especially if you want to share code and/or settings between the WebJob and your web app as they run in the same context, which also makes deployment quite easy.

Creating a Storage Account

Before we continue let’s take care of something first. A WebJob requires an Azure Storage Account.  I’ll quickly walk you through the process of creating one.

In Azure, find “Storage Accounts” and add one. You’ll have to pick a name that’s unique across Azure. Other than that you can leave the defaults. We’re talking about cents per GB, so don’t worry about costs too much.

Once your Storage Account is ready, select it and find your “Access keys”. We’ll need one of the two connection strings later.

Creating a WebJob

As said, there’s a WebJob template for the full .NET Framework. I recommend you check it out. Start by creating an ASP.NET Web Application and then add a new WebJob. If you try to create the WebJob right away you’ll get an error saying that the project needs to be saved first (although it does create the WebJob).

We’re here for the .NET Core version of a WebJob though. So start by creating an ASP.NET Core Web Application and then add a new .NET Core Console App project to your solution.

The first thing we need to do to is install the Microsoft.Azure.WebJobs package from NuGet. We should also install Microsoft.Azure.WebJobs.Extensions. Here’s the catch though, the latest stable versions of these libraries have dependencies on the full .NET Framework so we’re going to need version 3.0.0-beta5 (at the time of this writing), which is fully compatible with .NET Core.

Other NuGet packages we’ll need are Microsoft.Extensions.Options.ConfigurationExtensions (which also gives us the Microsoft.Extensions.Options package, which we also need), Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.Logging.Console. Be sure to install version 2.1.0 of these packages because there seems to be a bug in .NET Core 2.1 that prevents you from using packages with patch versions, like 2.1.1.

Join the Program

The next thing we need to do is change our Program.cs file. If you’ve created a WebJob using the .NET Framework template you can simply copy and paste the Program.cs file that was generated there (although you might want to change the namespace).

Adding Configuration and DI

So I promised you’d get all the .NET Core goodies like logging and DI. By default, a Console App doesn’t have any of that, but you can add it yourself.

Next, create an appsettings.json file and set the “Copy to Output Directory” property to “Copy always”. The appsettings.json file should have two connection strings as mentioned in the Program.cs template file. These are the Storage Account connection strings we created earlier.

The next thing we need is a custom IJobActivator that can be used to inject dependencies into our classes. It needs to be set on the JobHostConfiguration in the Program class.

Adding a Trigger

After that, create a class and name it Functions (just like in the WebJob template). The Functions class will have the actual code for our WebJob.

Of course, we’ll need to add a trigger. This is different than the full .NET Framework. After all, the template uses a static method, which makes DI impossible. Speaking of DI, notice that we’ve also added the Functions class itself to the DI container.

For simplicity, we’ll use a TimerTrigger, which is triggered with a so-called CRON expression. This simply means it’s triggered at a certain minute, hour, day, etc. In this example, it triggers every minute.

We’ll also need to configure timers on the JobHostConfiguration.

Running the example

If you did everything correctly, or if you’re running my code from GitHub, you should now be able to run the Console App. If you break on exceptions or if you’re watching the Output window you may notice a lot of StorageExceptions. Don’t worry about them and ignore them. This is a bug in the WebJobs library and will not affect your program. It may take a minute for your trigger to go off, so have a little patience.

If you head over to your Azure Storage Account you should see two Blob Containers, “azure-jobs-host-output” and “azure-webjobs-hosts”. There’s quite a lot going on here, but you can just ignore it. I’ve found that my WebJob triggers wouldn’t go off for some reason, deleting the Blob Containers usually helped. Apparently, there’s some state stored in there which isn’t always disposed of properly when (re-)adding and removing WebJobs.

Deploying to Azure

The next thing we want to do is deploy our WebJob to Azure. In order for a WebJob to run it needs some executable script that it can use to get going. Many file types are supported, but for us Windows users it makes sense to use an exe, cmd, bat or PowerShell file.

A Console App used to be an exe file, but in .NET Core, it produces a regular DLL file that we need to start manually. So, create a file and name it “run.cmd” and make sure that it’s encoded in UTF-8 no BOM (you can check this using something like Notepad++). It just needs a single line of code, which is “dotnet NetCoreWebJob.WebJob.dll”. This runs your Console App. Make sure you set the “Copy to Output Directory” of the file to “Copy always”.

One last thing, for some reason Azure WebJobs needs all the dependencies of a WebJob, which means all .NET Core packages we used to build it. You can do this by editing the csproj file and adding “<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>” to the first <PropertyGroup> (underneath “<TargetFramework>”).

Before we can deploy our WebJob we need to deploy our web app. Right-click the ASP.NET project and click “Publish…”. Simply follow the wizard and Visual Studio will deploy your app for you. You can create a new web app or select an existing one. This step isn’t strictly necessary as you can host stand-alone WebJobs, but this should be familiar and it gives you an App Service we can use for our WebJob.

Deploy using Visual Studio

Deploying WebJobs using Visual Studio should be easy as pie. In fact, you probably already know how to do this (don’t do it yet though). Right-click your WebJob project and click “Publish…”. The following wizard looks a whole lot like the publication of a web app, which we just did. You can pick “Select existing” and pick the Azure web app we just created.

Unfortunately, Microsoft messed up this feature in the worst way possible. Visual Studio will deploy the WebJob with the same name as the project, which is “NetCoreWebJob.WebJob”, except the dot is an illegal character in a WebJob name! This messed up my project so bad I had to manually edit it to make my solution working again. Nice one, Microsoft!

So here’s what you do. At the start of the wizard, where you pick either a new or existing App Service, click the arrow next to “Publish immediately” and pick “Create Profile” instead. Now you can first change the name of your WebJob in the settings and deploy after that. Make sure you don’t select “Remove additional files at destination”  or you’ll remove your web app.

Now, browse to the Azure Portal and look up your web app. You’ll find “WebJobs” in the menu. You’ll see your WebJob, but it’s not doing anything. You need to manually run it by selecting it and clicking “Run”. The status should update to “Running”. You can now check out the logs to see that it actually works. You may see an error about the connection strings, but you can ignore those. If you toggle the output you’ll still see a log is written to the console which lets you know it works! If you don’t see a log right away try waiting a minute or two and don’t forget to manually refresh the output.

WebJobs in Azure
WebJobs in Azure

Deploy using the Azure Portal

When you add a new WebJob you’ll need to fill out some options. You can make up some name, set the type to “Triggered” and the triggers to “Manual”. Your alternatives are a “Continuous” WebJob, which just runs and closes (unless you’ve implemented an endless loop in your application); and a “Scheduled” triggered job, which is basically what we have except we’ve implemented the schedule ourselves.

The “File upload” needs a bit of explanation. Here you can upload a zip file that contains your WebJob. So head over to Visual Studio and build your solution. Then go to the output folder of your WebJob project, something like “MyProject\bin[Debug|Release]\netcoreapp2.1”, and put everything in that folder into a zip file. Then select it in the “File upload” in your new WebJob.

Add WebJob
Add WebJob

It will take a few seconds for Azure to create your WebJob so keep refreshing until it pops up. After that, you have to start it manually again and you can check out the logs.

Deploy using VSTS

Ultimately, we want to add our WebJob to our CI/CD pipeline in VSTS. Unfortunately, this functionality doesn’t come out of the box. Luckily, it’s not very difficult either. If you’re not familiar with builds or releases in VSTS check out one of my previous blogs Azure Deployment using Visual Studio Team Services (VSTS) and .NET Core or ARM Templates to Deploy your Resources to Azure.

When you’re in the Azure Portal find the “App Service Editor (Preview)” of your App Service. This lets you browse all the files in your App Service. One thing we notice is that your WebJob is located in “App_Data\jobs\triggered[WebJob name]”. And since your WebJob is really just the output of the WebJob project build it’s simply a matter of copying your WebJob files to App_Data.

WebJob file location
WebJob file location

The build

So go to VSTS and create a new build. Select your repository, your branch, and select “ASP.NET Core” as a template. We only need to change two things here. We need to change the existing “Publish” task and add a new “.NET Core” task to publish our WebJob.

Change the name of the existing publish task to “Publish web app”, untick the “Publish Web Projects” checkbox, and enter the “Path to project(s)”, which is “**/NetCoreWebJob.csproj”. Also, untick the “Zip Published Projects” and “Add project name to publish path” checkboxes as they will eventually mess up our release.

After that create a new .NET Core task, set the “Command” to “publish” and change the name of the task to “Publish web job”. Again, untick “Publish Web Projects” and set the “Path to project(s)”, which is “**/NetCoreWebJob.WebJob.csproj”. And once again, don’t zip the published projects or add the project name to the publish path. The last step here is the “Arguments” field, which can be copy/pasted from the other publish step, except we’re going to add a bit to it: “–configuration $(BuildConfiguration) –output $(build.artifactstagingdirectory)\App_Data\jobs\triggered\WebJobVSTS”.

VSTS WebJob build
VSTS WebJob build

The release

Last, but not least, is the release. Create a new release in VSTS, pick the “Azure App Service deployment” template and fill in the blanks, which is an artifact and your Azure settings in the Environment. Because we’re not zipping our build we just need to change one setting. In the “Deploy Azure App Service” task is a “Package or folder” setting, which has a default of “[…]/*.zip” which obviously isn’t going to work. Instead, use the browser (the button with “…”) and select your drop folder.

Save it, hit new release and pick your latest build. If all goes well you should see your new WebJob in the Azure Portal!

Wrap up

Hopefully, Microsoft will come with a built-in solution for creating, consuming, and deploying WebJobs to Azure in .NET Core soon. Until that time it’s not particularly difficult, it’s just a matter of knowing what to do.

In this post, we’ve seen the TimerTrigger, but there’s a QueueTrigger, a BlobTrigger, and a FileTrigger as well. Experiment, google, and read the official documentation.

Don’t forget to delete your resources.

Happy coding!

Azure, CodeProject, Software Development

ARM Templates to Deploy your Resources to Azure

Leave a comment

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, CodeProject, Web Development

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

Leave a comment

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!