In a series of posts, some of the features available in Azure and Visual Studio Team Services will be explored. The posts will use an Azure Web App website as a practical illustration, and many of the features shown are relevant to other types of Web Apps and components in Azure.
VSTS Build is an excellent mechanism for enabling automation for a development team. It allow for teams to construct build pipelines to handle a variety of scenarios and technology. The service can run hosted or on-premises, and supports a large number of build steps ranging from Node.js and Gulp to MSBuild and Azure Deployment. Its flexibility extends to the ability to bring in tasks from the Marketplace and write custom build steps.
The solution used to build the build pipeline series has been uploaded to MSDN Sample Projects.
This post, Part 1, is concerned about:
- Creating an Azure Web App website using the Visual Studio Cloud template
- Enabling Application Insights
- Creating a local Git repository
- Creating a remote Visual Studio Test Services Git repository
- Creating a VSTS Build definition
Continuous Deployment, Continuous Delivery, Continuous Integration
There are many resources that do an excellent job of defining these terms:
- Continuous Delivery vs Continuous Deployment vs Continuous Integration - Wait huh?
- Continuous Integration
- Continuous Delivery
and describing the benefits:
An ASP.Net Web Application will be used as base for the posts. Note that Application Insights and a local Git repository were created:
To keep the project simple, the MVC template without authentication was selected. Note that a Unit Test project and hosting in Azure were selected at creation time:
One nice feature of the setting up a project using the template is the creation of the initial App Service.
Once the project wizard completes we have:
- An empty Azure Web App website
- A local GIT repository
- An Application Insights resource in Azure
The project can be run locally and in Azure but the Azure project just states it is empty as nothing has been deployed yet:
Adding to Visual Studio Team Services GIT
To get the project into the hosted website, the following will be performed:
- Add the project to a VSTS Git project
- Create a build to deploy the project
The Team Explorer window can be used to save the changes to your local repo. It also detects that the local repo is not connected to a external GIT service. Visual Studio allows the local repo to be saved to a VSTS, GitHub and other remote GIT services like BitBucket.
The following shows the settings for publishing to a VSTS Git repo:
- Develop and share using GIT
- Gettings started using GIT in Visual Studio
- VSTS Getting Started
Now that the source has been published to GIT, a VSTS Build Definition can be defined. For this scenario, a Azure WebApp Deployment template will be used as a basis for the definition:
The template allows the repo to be specified:
The template creates a classic Azure Web App Deployment.
Note: the replacing of the Azure Web App Deployment task should only be done if the VSTS subscription has access to the AzureRM Web App Deployment task.
Though we could use this task to deploy to both classic and RM Azure web sites, I will replace it:
And instead create a AzureRM Web App Deployment by adding the following task:
The configuration of the build step requires an AzureRM Subscription endpoint is defined in Services (click Manage) and requires the Web App Name and package is specified:
The rest of the steps ares suitable for the project. The final pipeline for Part 1 consists of retrieving the source from a GIT repo, restoring NuGet packages, building the solution, running the unit test project, publishing to Azure and saving the build artifacts. This is shown below:
The build can then be queued. If all goes well the build will complete including a deployment to Azure.
Unless the template is updated, the build will fail because of a missing file. By default the applicationinsights.config file is ignored and not added to GIT. Including the file will allow the build to succeed.
In Part 2, we will look at changing Application Insights settings in the build pipeline.