Building an ASP.NET Core Web App in Visual Studio Team Services (VSTS)

This is part of a series of articles comparing the experience of developing, deploying and maintaining an ASP.NET Core 2.0 web app on the PaaS offerings from Azure, AWS and Google Cloud Platform. You can find the introduction and contents here .

Articles in this series

1. Introduction
2. Introducing the PinotageToDo App
3. Building an ASP.NET Core Web App in Visual Studio Team Services (this article)
4. Hosting an ASP.NET Core Web App in an Azure App Service

Building an ASP.NET Core Web App in Visual Studio Team Services (VSTS)

There are many options for automating the build and deployment of ASP.NET Core web apps. For the purpose of this series we are going to use Microsoft’s Visual Studio Team Services (VSTS) to host our git repository and manage our build and release pipeline.

The Build and Release features in VSTS allow you to customise your build and release process pretty much exactly the way you would like it. We are going to keep it real simple for now:

Build steps (what this guide will cover):

1. Get the code
2. Get any dependencies
3. Build
4. Run Unit Tests
5. Package (publish) our web app artifact

Release steps (will be covered for each platform we deploy to in separate posts):

1. Take the artifact from the build process and deploy to our target environment

The steps below assume that you already have a VSTS account, have created a team project and have your code in a git repository (in VSTS in our case, but GitHub, Bitbucket and remote repos are also supported).

If you are new to VSTS, you may find the following guide to the VSTS web portal useful. https://docs.microsoft.com/en-us/vsts/user-guide/work-web-portal

1. From within your VSTS project site, click on the Build and Release hub.
2. The Builds page should be selected by default, if not, navigate there.

3. Click on the New button. The Select a template dialog will display.

4. Choose the ASP.NET Core template. This template will create a basic build definition for us which we can then customise to finish our build.

5. The Process tab only needs the Agent queue to be completed. We want our build to run on a hosted (i.e. in VSTS) agent that runs Visual Studio 2017, so choose Hosted VS2017 in the Agent queue dropdown.

6. Now we need to tell the build where our code lives. Click on the Get sources item in the left-hand list. For our example the repository lives in the same VSTS project as the Build Definition, so we choose “This project” and select the repository from the Repository drop down. We are building from the master branch so we can leave that drop down as is and we can also leave Clean as false.

7. Let’s review the tasks that were created for us when we chose the ASP.NET Core Build Definition template. For our example the default settings for the tasks that have been created are all that is required.

8. Click on the Restore task in the left-hand list. This task will restore the NuGet packages required by the project. By default it will use a wildcard match to restore packages for any .csproj project which is exactly what we want.

9. Click on the Build task in the left-hand list. Unsurprisingly, this builds the project, again using a wildcard match in the Project(s) text field to build any .csproj project it finds. Note that by default the task will pass the value of the BuildConfiguration build variable to MsBuild. Since we will be running the build manually we will see when we queue the build where the value of build variables is set.

10. Click on the Test task in the left-hand list. Our example solution includes some XUnit test projects that we want to execute during our build. Again, the build task uses a wildcard match to specify that any .csproj projects that contain “Tests” in the name will be executed.

11. Click on the Publish task in the left-hand list. This task runs the publish command against any web projects (the build will identify a web project by the presence of a web.config file or wwwroot folder in its folder structure). This produces the artifact(s) that we will want to deploy, but does not do any deployment itself. By default the folder (and all its contents) that is created by the publish command will be zipped.

12. Click on the Publish Artifact task. This is the final step of our build definition. The purpose of this task is to copy the zip file that was created by the previous step to a location that we can access once the build has completed (remember that we are using a build agent that was spun up just for this build, as soon as the build completes the agent will be destroyed). By default the artifacts are published to VSTS. This suits us just fine because we will define a Release definition to pick up the artifact from there and deploy it to our target later in this post.

13. That’s it for the build. Let’s see if it works. Click on the Save & Queue button. A “Save build definition and queue” dialog will appear. Remember when we were looking at the Build task I mentioned the BuildConfiguration variable. Here you can see that is defaulting to release. We also have BuildPlatform and system.debug variables. You can safely leave everything as is and click on the Save & queue button.

14. The dialog will close and a message will appear saying that the build has been queued.

15. If you click on the build identifier in the message the Build dialog will open and you can follow the progress of the build.