April 16, 2017

/

Deploying ASPNET Core Apps with VSTS

Deploying ASPNET Core Apps with VSTS

Although .NET Core has been out for a while the tooling was still in preview when it was released. Now that Visual Studio 2017 has been released the RTM (Release To Market) version of the tooling for building and publishing .NET Core are available. This includes the the .NET Core Command Line Interface (CLI). However as anyone who has used Visual Studio Team Serves Hosted Build Agents knows that using the latest tools without forking out for your own build VM to put a build agent on is not always that simple…

Luckily there are Visual Studio 2017 hosted agents available you just have to make sure to select it in the options. I’m going to show you how to create a build and release for .NET Core using VSTS Build and Release and Azure Web Apps.

Creating the build

This article is going to assume you already know how to create a project and add some code to repository. This tutorial is going to use the code that is found in https://github.com/sethreidnz/dotnet-core-vsts-sample which is a basic .NET Core ASPNET MVC app created using the .NET Core CLI that is found in the path server/DotnetCoreVSTS.Server.

The easiest way to follow along would be to fork my code on Github and use your repository as the source to build from.

Create the initial build definition

  1. Log into your Visual Studio Team Services account and go to the project where we are going to add the build
  2. In the main navigation click Build & Relase
  3. Click on the + new button to create a new build

    NOTE: There are currently two different interfaces for the build tools as they transition to the new updated interface. My instructions are for the new look but the terminology is similar so it should be possible to follow along.

  4. Click on empty process
  5. In the name text box enter “Dotnet Core VSTS”

  6. Click on Save & Queue and then click on Save

Connect to the repository

This step you can connect to your own repository if you like. If the code or structure of your project is different some of the following steps will need to be customized. For pure learning purposes you could fork my github repo and use that as your source. Here are the steps:

  1. Click on the Taks tab
  2. Click on the Get Sources task that is in the list

  3. In the From field select Github

  4. For Connection Name enter “Dotnet Core VSTS Connection”

  5. Click on Authorize Using OAuth

  6. In the Popup enter your Github credentials and authorize VSTS to access your account

  7. Back on the Tasks tab after you have completed OAuth for Repository add the repository you would like to use (the forked version of mine if you like)

  8. Click on Save & Queue and then click on Save

Configure the build agent

While the default build agent is still using Visual Studio 2015 we need to make a change to ensure we are using the latest .NET Core CLI:

  1. Click on the Options tab
  2. Find the Default agent queue input and select “Hosted VS2017”

  3. Click on Save & Queue and then click on Save

Add our build variables

We are going to add a few variables to allow our build to be configurable:

  1. Click on the Variables tab
  2. Click on the Add button

  3. Enter the name “build.configuration” with the value “release”

  4. Enter the name “build.platform” with the value “any cpu”

  5. Click on Save & Queue and then click on Save

Add the build tasks

Next we need to add the build tasks to create a release package from our .NET Core source code:

  1. Click on the Tasks tab
  2. Click the Add Task button. To learn more about Build and Release Tasks read the documentation here

Restore dependencies

  1. Create a Command Line Task (under Utility)
  2. Add the following values

  • Display Name: Restore Dependencies
  • Tool: dotnet
  • Arguments: restore
  • (Under advanced) Working Folder: server/DotnetCoreVSTS.Server

    NOTE: This will restore the Nuget packages for the MVC app in the repository

Build the app

  1. Create a Command Line Task (under Utility)
  2. Add the following values
  • Display Name: Build
  • Tool: dotnet
  • Arguments: build -c $(build.configuration)
  • (Under advanced) Working Folder: server/DotnetCoreVSTS.Server

    NOTE: This will create the release build artifacts for publishing

Publish the app

  1. Create a Command Line Task (under Utility)
  2. Add the following values
  • Display Name: Create release package
  • Tool: dotnet
  • Arguments: publish -c $(build.configuration) -o $(Build.ArtifactStagingDirectory)
  • (Under advanced) Working Folder: server/DotnetCoreVSTS.Server

    NOTE: This will create the published version of our .NET Core app the staging directory. $(Build.ArtifactStagingDirectory) is a predefinted variable provided by VSTS

Create release package

  1. Create a Archive Files Task (under Utility)
  2. Add the following values
  • Display Name: Publish
  • Root folder (or file) to archive: $(Build.ArtifactStagingDirectory)
  • Prefix root folder name to archive paths: Unchecked
  • Archive type: zip
  • Archive file to create: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip

    NOTE: This step zips the staging directory contents to create a publish package for the deployment to Azure

Publish release package

  1. Click on Add Task and use the search box to add a task “Publish Build Artifacts”
  2. Add the following values
  • Display Name: Publish Package
  • Path to Publish: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
  • Artifact Name: drop
  • Artifact Type: Server

    NOTE: This step takes the zip file created in the last step and puts it in a publish package called “drop”

  1. Click on Save & Queue and then click on Save

Testing the build

Now that we have all the steps in place the hard work is done. You can test this by clicking Queue from the edit/create build page. IF all goes well then you should have a successful build. One way to check if it was successful is to look at the artifact created by the final step. To do this:

  1. Click on the Build & Release tab
  2. Click on the build that we just created
  3. Click on the build number link on the latest build under Recently Completed to go to a summary of that build

  4. On the right hand side click on the Artifacts under the “Build Succeeded” message.

  5. Click on Explore

This lets you explore the release package that was created as well as download it and explore. This release package only has the ZIP file with the website code we created in it:

Exploring VSTS Release package

Creating the web app

The next thing to do is to create a web app we can deploy our release package to. First you need to log into your Azure subscription and if you don’t have one then create one here.

  1. Go to portal.azure.com
  2. Follow the login prompts

  3. At the top right click on New

  4. In the search box type Web App and press enter

  5. Click on Web App and then click Create on the next blade

  6. Give the app a unique name for example sethreid-dotnetcore is what I used.

  7. Select the subscription (if you have more than one)

  8. Under resource group select Create New and call it the same name as the web app (e.g. “sethreid-dotnetcore” in my case)

  9. Select Pin to dashboard

  10. Click Create

Now we have a web app to deploy to lets setup the release definition

Creating the release definition

This is the final thing we need to do which is tell VSTS when and how to deploy the release package when our build creates it. Creating release steps is very similar to the build steps except you can create multiple releases for each build so you could test it in various environments from the same build. We are going to set up one release to happen when a release package is created by our build.

Create the new Release Definition

  1. In VSTS hover on the Build & Release tab and click on Releases
  2. Click on New Definition

  3. Click on Empty for the template and press Next

  4. Select the correct project and build definition from earlier

  5. Check the box next to Continuous deployment and press Create

    NOTE: This will bring you to the Release definition edit page

  6. Click on the pencil next to the definition name at the tope and give it the name “Dotnet Core VSTS Release”
  7. Press Save

Creating the deployment task

We could have used a template for this but I wanted to show you how it’s pretty simple to deploy to Azure since we only need one task. Follow these steps from the release definition edit page:

  1. Click on Add Tasks in the middle of the screen
  2. Find Azure App Service Deploy and click Add

  3. Click Close

  4. In Azure Subscription select the subscription you created the Azure web app in

  5. Click the Authorize button next to the subscription name (if its there)

  6. Under App Service Name select the web app created earlier

  7. Leave the rest default and click Save

Testing the release

Now that we have created the release lets test deploying the release package we built earlier.

  1. From the Release tab in VSTS locat the release defintion we just created
  2. Click on the Elipsis (…) next to it and click Release

  3. Leave the defaults and click Create

If all went well you should see the Release as successful in the list (this may take a few minutes and you have to refresh the page). You should also be able to visit your web app and see the .NET core app deployed and working. The build will be kicked off when ever you check in new code to master and if that build is successful it will be published to the Azure Web App!

Seth Reid

/

Deploying ASPNET Core Apps with VSTS