# Setting up CI for ASP.NET MVC to deploy on Azure Cloud WebApp using Visual Studio Team System
**by:** Saurabh Nandu     **in:**  [DevOps](https://www.systenics.com/blogs/category/devops)     **tags:**  [*Visual Studio*](https://www.systenics.com/blogs/tag/visual-studio) ,  [*Continuous Integration*](https://www.systenics.com/blogs/tag/continuous-integration)
## Overview

Importance of DevOps is growing by the day as development teams adopt
agile practices and start on the path of shorter development cycles.
Having a good Continuous Integration system in place is one of the key
parts of DevOps setup. In this blog I will explore the process of
getting a simple ASP.NET MVC application configured using Online Visual
Studio Team System's Build and Release process to deploy to an Azure
WebApp.

Microsoft has a great offering in Online Visual Studio Team System which
is robust as well as feature rich and best of all its free for up to 5
users, even for private projects! Microsoft Azure has been a competitive
cloud offering and its WebApps service is a perfect choice for ASP.NET
MVC applications as it takes away the hassles of maintenance of VM and
provide some great scaling options. In this blog I will use the default
VS generated ASP.NET MVC 5 application and configure it in VSTS for CI
deployment to Azure Web App.

## Setting Up ASP.NET MVC Project

Our focus is not the MVC application but the configuration of the CI
process, hence I choose use the default VS generated ASP.NET MVC
application to get started. So fire up Visual Studio and create a new
project using the **ASP.NET Web Application (.NET Framework)** template. Select **Create new Git repository** option on the
**New Project** dialog as shown in **Figure 1** below to initialize the Git repo. Later, we will connect this Git repo with
the remote VSTS based Git repo.

**Figure 1:** New Project dialog – Visual Studio

On the **New ASP.NET Web Application** dialog select the **MVC** template. Select the **Add unit tests** option so that a test
project is added to our solution. Later, we would want to run the tests on
CI to ensure our build was successful. Also click on **Change Authentication** button and select the authentication type as **Individual Users** as shown in **Figure 2** below. Click **OK** to
create the new project.

**Figure 2:** New ASP.NET Web Application

Build and run the project to ensure its working correctly locally. Run
the tests from the **Test** menu to ensure they succeed, at this
point the tests are auto generated and simple calls to the home controller
but enough for purpose of our blog.

## Configuring Entity Framework Migrations

Although the default ASP.NET MVC project is pretty straight forward and
easy to setup, it presents a challenge from CI perspective. The default
ASP.NET MVC project uses Entity Framework Code First approach to upgrade
the database. While the process of database migration is straight
forward while publishing directly from Visual Studio, it presents
several challenges when we try to achieve it during CI. The general
recommendation is not to use Entity Code First approach if you want to
go down the CI route and instead use the MS Database project or several
other database migration options available.

In case you still wish to stick with using EF Code First approach, then
there are two main options available. The first, most logical one for
large projects, is to package EF tool migrate.exe along with your
project and then invoke it during the CI release process. One most
important point to remember is that the agent running the Release
process needs to be able to connect to the Azure Database server, so you
need add appropriate firewall rules before you run the migrate tool.

The second approach, more suited for smaller projects but definitely not
suited for a live production system is to modify the project codebase to
run migrations when it first connects to the database server. In this
case the database will get migrated after it build is deployed to the
server and if anything goes wrong during migration you will not be able
to roll back the build! I will use this approach in the current blog
because EF migrations would make a separate blog entry, but at least it
will provide some support for migrations in the current blog scope.

Open the Package Manger window in Visual Studio and run the
enable-migration command to enable migrations for the project and let
the initial migration scripts be generated. Then open the Startup.cs
file and update it to include the additional using statements as well as
to set EF to migrate the database to the latest version.

```
using Microsoft.Owin;
using Owin;
using System.Data.Entity;
using TestMVCApp.Models;
using TestMVCApp.Migrations;

[assembly: OwinStartupAttribute(typeof(TestMVCApp.Startup))]
namespace TestMVCApp
{
public partial class Startup
{
public void Configuration(IAppBuilder app)
{
ConfigureAuth(app);
Database.SetInitializer(new MigrateDatabaseToLatestVersion<ApplicationDbContext,Configuration>());
}
}
}

```

Next, open the auto-generated **Configuration.cs** file from
the **migrations** folder and add the following lines to the
**Configuration** method to ensure that migration scripts run
automatically when the application is invoked.

```
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;

```

You can build and ensure that the project is building and working fine
locally.

## Sync Project with VSTS Git Source Control

Now that our project is ready, it's time to upload it to online Git
repository. You need to use your Microsoft Credentials to signup and
create a project on [VisualStudio Online](https://www.visualstudio.com/vso/) (if you don't have one already). It's free to create unlimited private projects
to be shared up to 5 users. Once you have created your project, navigate to
the **Code** section of your project to get the URL to the Git
repository of you project. Copy the Git Repository URL shown on the page,
we will need it to add our project to source control.

Since we have already crated a VS project in the steps above we need to
add it to the remote Git repository. In Visual Studio, open the Team
Explorer and click on the Sync button as shown in Figure 3 below.

**Figure 3:** Sync with Remote Repository

VS will recognize that we do not have any remote Git repo associated
with our codebase and give us an option to connect with an online Git
repo as shown in **Figure 4.**

**Figure 4:** Publish Git Repo

Click on the highlighted **Publish Git Repo** button and follow
the wizard to login into the Microsoft Account, use the same account which
has permissions on the Visual Studio Online project that we crated earlier.
Once you are logged into your Microsoft account you will be presented with
a screen similar to Figure 5, which allows you to choose your VSTS Domain
and the Project that you wish to use for this application.

**Figure 5:** Select VSTS Project details

Make sure you have the right project details setup, click on the **Advance** button in the screen above to input the name of the Team Project in which
you want to host the source for this application. Finally click on **Publish repository** button to push the local git changes to the VSTS hosted remote repo. Now
that our online Git repo is ready we can move ahead with the CI configuration.

## Azure Web App and SQL Server

Creating and configuring an Azure Web App and SQL Server are out of the
scope of this article. I assume you have one created and have the
required parameters and credentials noted down. I am using the Web + SQL
azure template to create a Basic version of the Web App and Free SQL
Server for lower costs in the demo. Make sure that you have correctly
changed the connection string in your project to point to the Azure SQL
DB, so that your application can connect with the Azure SQL DB.

## Configuring Azure Account as a Connected Service in Online VSTS

Navigate to the online VSTS website and login to your project in which
you wish to automate the build. You will see a **gears** settings
icon once your project is selected, hover over it and select **Services** from settings menu as shown in figure 6.

**Figure 6:** Select Services setting for VSTS Online

On the Services page click on the **+ New Service Endpoint** button and select **Azure Resource Manager** from the list
of options. Provide a Connect Name that's easy to remember and select the
Azure Subscription that you are trying to connect. It's always easy if both
your VSTS and Azure accounts share the same Microsoft account. Also remember
the you need to have admin permission on both the VSTS Online Project as well
as in Azure to be able to perform this step. If you do not have appropriate
permissions in Azure as well as the Default Azure Active Directory for your
account you will run into all kinds of permission errors! Once you have the
Azure service connected in VSTS we can proceed to configure our Build process.

**Figure 7:** Add Azure Resource Manager Service Endpoint

## Configuring VSTS CI Build Automation

In VSTS online, click on the **Build & Release** menu and
select **+ New** to add a new Build Definition. Select **ASP.NET (PREVIEW)** from the template library and click **Apply** to load a default
set of tasks used to ASP.NET projects as shown in **Figure 8**.

**Figure 8:** Add new Build Definition

VSTS Online build definition provides various in-built templates for
popular application types. You can also start with an **Empty Template** and add your own Build Tasks. In this blog, I am using the **ASP.NET** build template which is perfect for our current requirements. **Figure 9** shows a list of build tasks that have been configured by default. They get
the source from Git, built it using VS, test it and finally copy the source
code for deployment.

**Figure 9:** ASP.NET Build tasks

You can click around in each of the Build tasks to look at their
parameter values and change it appropriately as required. New tasks can
also be added and ones like Public symbols path, if not required can be
removed as well. Switch to the **Triggers** section on this screen
to configure Continuous Integration, turn on the **Enable this trigger** option and you will see that it auto populates the name of the repository
being used as well as its branch to monitor. By default, any changes pushed
in the **master** branch will trigger the build. That is the
correct setting for us right now but if you have multiple different branches
for development and production you can configure the it from this screen as
shown in **Figure 10**. I will leave the default template
values and click on the **Save** button (under **Save & Queue**) menu above to save the template.

**Figure 10:** Configure CI Trigger

## Configuring VSTS CI Release Automation

Now that we have configured our Builds to auto trigger on every branch
push, we also need to configure the Release of the build to our azure
web app. Switch to the **Releases** tab in online VSTS and click
on **+ New definition** to create a new Release definition. Select
the **Azure App Service Deployment** template and click **Next**, as shown in **Figure 11**.

**Figure 11:** Create release definition

The next screen allows you the view the project name and the source
control name, let these values be at default. Select the **Continuous deployment** checkbox to ensure that as soon as a build is completed, its auto released
to Azure. Click Create to create the release definition.

**Figure 12:** Create release definition – 2

Once the release definition is created you will see tasks listed for **Environment 1**. Select the **Deploy Azure App Service** task and input the
**Azure Subscription** and **App Service Name**. We had earlier linked our VSTS to Azure for this reason so that the
Subscriptions and App Services get auto populated and linked. The VSTS
automatically takes care of managing the credentials and uploading to
the Azure App Service.

**Figure 13:** Deploy to Azure App Service

Switch to the Triggers section and set the Branch name as **master** as shown in Figure 14 so that our release is triggered every time a build
is available for the **master** branch. Click on the **Save** icon to save our changes. This completes our basic configuration of VSTS
Build and Release configuration. Now we are all ready to test out our CI platform!

**Figure 14:** Setup Release Trigger

## Testing Our Configuration

You can make some changes to any of your files and push a change to your
source control. This should trigger an auto build as we have configured
it. On the VSTS portal as soon as a new push it made to Git, it will
auto-trigger a build. You can see in Figure 15 that a Build is in
progress. Clicking on the build number will take you to the Build
Details and you can see a complete log of the build progressing on the
Build Agent. At times, I have seen that the Build fails when it's not
able to download NuGet packages or NPM packages. So, it's essential to
monitor the build and Queue it again in case you see such errors.

**Figure 15:** Build in Progress

**Figure 16:** Build Status and Details

**Figure 17:** Unit Tests Successfully run on Build Agent

Once the Build is completed, it's artefacts are version and uploaded and
it triggers the Release process. You can monitor the progress if the
release from the **Releases** tab and clicking on the release
number in progress as shown in **Figure 18**. You can see
below that my release has succeeded and the build has been deployed to
the server.

**Figure 18:** Release Status

Once the release is successful launch the application in your browser
using the Azure Web App site URL, navigate to the Register page and
register a new user. This will trigger Entity Framework to start
creating the tables on the new Azure SQL Server database. Every time you
modify the schema of the database, ensure that you run migrations on
your project locally and then once the build is published run the page
like Register or Login which will internally cause Entity Framework to
start the database migration process on Azure SQL Database.