Visual Studio Team Services - Creating a build pipeline (Part 2)
In part 1, a basic Azure Web App website was built and deployed using VSTS Build. In this post, Application Insights will be explored including modifying the build process to only include the Azure website activity. The intention is not to repeat what has been provided in other resources, for example those in the references below, but to highlight some things that might not be obvious or intuitive.
Azure Portal Application Insights Blade
The Application Insights blade in the Azure Portal can be opened by using browse as shown below. Note the star to save to the left shortcuts menu.
The following is an example for the deployed website. Besides the obvious summary of activity shown in the Application Health tile is the Instrumentation Key and the Live Stream.
Note the Live Stream first. If we have both our Azure website and our local website running at the same time the Live Stream count is increased to 2 as shown below:
This is because both are set to report to the same Application Insights. This is controlled by the InstrumentationKey element in the ApplicationInsights.config.
Tip: The Server Explorer in Visual Studio can be used to browse and update the content of the website as shown above.
References
- Application Insights
- Get started with Visual Studio Application Insights
- Application Insights Overview
Updating InstrumentationKey for different environments
For this scenario the requirement is to not include the development machines activity in the Application Insights data. We then need a mechanism to clear the InstrumentationKey from the ApplicationInsights.config on the development machines and include the key only when we build for a release. There are several ways to do this from powershell or other scripts (see Alex's post) to using Slow Cheetah to apply transforms. In this example, we will take more control of the packaging of the website and include the file as part of publishing the project.
In our solution, we will create a new folder called Resources and add a copy of the ApplicationInsights.config file containing the InstrumentationKey. We will need to add this to Git which will most likely require an edit to the .gitignore file. Below is an example extracted from a modified file which states to ignore the ApplicationInsights.config file unless it is in the Resources folder:
Build solution
At the moment, the build step Build solution **\*.sln is receiving several parameters which cause a package (re., a zip file) to be created of the built solution. This is no longer adequate for our purposes as we need more control than is supported by the parameters. Instead wer are going to build the solution, perform our unit tests and then package the website in preparation for deployment.
The default build step is shown below:
Now that we are not going to package immediately we will no longer pass any parameters so the MSBuild Arguments will be cleared.
Tip: The $(BuildPlatform) and $(BuildConfiguration) are referencing the Build Variables shown below:
Web Deployment Package
As there are many good resources on creating a web deployment package so I will not cover this here and instead show the steps required after the publish profile has been created. See the References section for some links.
In the project, select the publishing profile that was created:
The file should contain a single TargetGroup element with the required information to create the package. We will add a new Target that copies the ApplicationInsights.config file from the Resources folder to our web project.
References
Build Step
After the unit tests have run, we will add a Visual Studio Build step to publish the website into a deployment package.
The step requires the project and the publishing profile to be specified as shown below:
The deployment step and the publish of the artifacts step will also need to be amended to reference the new location of the deployment package. As an example, deployment step is shown below and refers to the package located in the Releases folder.
Summary
The following shows the current build pipeline:
If any of the steps fail then the build will be aborted. This means our unit tests must pass in order for our web deployment to be successful. Just having Continuous Integration (CI) causing the build process to run has large benefits for the team by detecting issues early. CI is controlled on the Triggers tab and controls both builds on check-in and builds on a schedule.
Next Steps
In Part 3, we will look at bringing Gulp into the build pipeline.