The entire DevOps story with the Microsoft Stack is expanding its reach to more and more services and with an ever-growing set of advanced features. During this article, I will cover the benefits and ways to configure Service Endpoints within either Visual Studio Team Services and Team Foundation Service, in order to create a highly coupled ALM story for your apps.

What are Service Endpoints?

Back in the days of Team Foundation Services (2013 and prior to that), everyone was asking for a way to make Release Management expand to other project types rather than .NET and VB/C++. Taken this feedback (along with many other requests) Microsoft rewrote Team Build. Personally, I believe the entire DevOps story using the Microsoft Stack has become more mature than ever and ready to solve the most complex requirements your application has. In order to achieve this type of extensibility, Team Build allows one to add features in two ways: (1) by installing extensions which can either be wrote and uploaded by yourself or by installed from the Visual Studio Marketplace or by (2) taking advantage of the TFX Command Line Interface which allows you to add custom designed tasks. The latter is especially useful when it comes to creating a single-task functionality as an atomic process part of the build or release definition, rather than leverage several tasks individually. This ensures that in the situation of build and release processes which have to do the same tasks over and over again a few times are easily configurable and thus reduces the error-prone nature of a highly-configurable workflow system, such as Team Build.

The beauty of these tasks are that they are not exclusively designed to Microsoft-specific products and services – in fact, most of the tasks which have to deal with external services will specify the external service’s endpoint in the form of a connection setting which is team-project wide. Again, this helps prevent errors related to connection strings and such.

These connection settings are known as Service Endpoints and can be configured from the Settings pane of any team project, both in Visual Studio Team Services and Team Foundation Services, under the Services tab.

Visual Studio Service Endpoints

Read More →

First of all, if you’re new to Application Insights, check out this link and this link too. In a word, Application Insights offers you deep insight data on your application performance and usage. And it rocks while doing that, too! :)

Application Insights is since last week no longer under preview. However, if you’re trying out Application Insights right now, you have obviously already found out that the corresponding NuGet package is still in beta (version 0.7.x.x) and, should you have tried out Application Insights for a longer time now, you’ve probably realized that there are a lot of changes in the configuration schema too.

One of the things I don’t like about the new schema is the lack of a special component ID (which basically defines a specific Application Insights entry = application) for debugging. This also means that when you debug, you’ll get your debug data mixed with the production data, which is bad.

However, even if the guys at Application Insights (which I’ve just met at Build 2014) have removed this one particular feature (which, I admit, didn’t work out for me as I expected), they’ve added tons of new features which are worth checking out.

Now, to the post subject. How do you collect usage and performance data if you have different cloud projects (for different environments, such as a staging and a production environment) and a single code-base (meaning, a single project containing your code). The question might be tricky, since you’ll have to add the .config file directly inside your project that contains your code (for example, the web project), rather than the cloud project.

For such a scenario, here’s what I did. I created a new folder inside the project folder (e.g. ‘AppInsightsConfigs’) which contains my applicationinsights.config files that correspond for each environment. This basically gives me the option to define a config file for the staging deplyoment (ApplicationInsights.Debug.config) and another file for the production deployment (Applicationinsights.Release.config). Obviously, each .config file has its own ComponentId and ComponentName settings.

What I do next is to create either a pre-build or post-build command that contains this simple command line:

copy  “$(ProjectDir)AppInsightsConfigsApplicationInsights.$(ConfigurationName).config” “$(TargetDir)ApplicationInsights.config”

This command simply writes either the .Debug.config or .Release.config over your output directory, which works fine for me since I want to have the Debug version in a staging enviroment (for remote-debugging scenarios especially) and a Release version in the production environment (who would add the debugging symbols and loose the code optimization feature inside production?!).

One thing worth mentioning out is that if you rung this as a pre-build or post-build command, you will not get the right version of the .config file unless you exclude or change the name of the ApplicationInsights.config file the Visual Studio Application Insights extension automatically adds (or the one you’ve added manually). Moreover, if you decide to run the command as a pre-build command, you also have the option of replacing the $(TargetDir) macro with the $(ProjectDir) macro, which will copy the desired configuration file over your original ApplicationInsights.config from the root directory, so that no exclude or rename is necessary. However, in this case please keep in mind that any change you do inside your ApplicationInsights.config file will be lost the moment you run a build command. I also don’t recommend you to run the command as a post-build command with the $(ProjectDir) macro as the destination folder, because you’ll need to build you project twice for the command to work and I’m sure you’ll almost certainly forget to do so :).