Visual Studio Team Services on Tiago Pascoal

VSTS: Collect Telemetry for build and release tasks using Application Insights

Mon, 13 Nov 2017 23:15:40 +0000

Developers of extensions for Visual Studio Team Services (or Team Foundation Server) tend to use Application Insights to collect telemetry about their extensions.

Metrics like usage, performance, errors are collected to know which features are used, which features are working, how they are performing and if they are failing to improve them and better deliver value to its end users.

There are several types of extensions

Dashboard widgets
Hubs
Actions
Work Item form elements
Build and release tasks

Except for build and release tasks, all other extensions types run in a web browser, so it is easy to collect telemetry and Application Insights is a natural fit.

VSTS: Generating badges for Releases

Wed, 01 Nov 2017 15:57:54 +0000

Visual Studio Team Services (and Team Foundation Server) supports build badges out of the box giving you an URL for an image that can be embedded in a web page (eg: a wiki or a GitHub page) to visualize the (always updated) status of a build.

Unfortunately Release Management doesn’t offer the same support for releases, fortunately it easy to implement a release badge generator with a few lines of code and using VSTS built-in extensibility mechanisms.

VSTS Extensions: Improving load time by concatenating modules

Tue, 16 Aug 2016 06:00:00 +0000

Introduction

When implementing a Visual Studio Team Service (or TFS) extension it is a good practice to split your code among several modules and load them dynamically with the provided AMD loader using the require/define function to load modules asynchronously.

While having one file per module, improves code legibility and reuse it can have some performance penalty to load many files separately.

In this post I will show you a technique where you can still have all the benefits of organizing your code in several files (one per module) with all the benefits that this brings and at the same time improve your load time by combining your modules into a single file.

Sharing secrets among Team Build and/or Release Management definitions

Fri, 15 Apr 2016 23:47:35 +0000

When creating a team build 2015 (often called build v.next) or a release management definition, you can store secrets in variable (for example for passing a password or a token to a task).

Secret variables cannot be seen when viewing/editing a build definition (hence the name secret), only changed.

Secret variables have some disadvantages

Their scope is limited to the build/release definition, if you want to use the same secret among several definitions you have to replicate them among the definitions
You can’t apply security to variables, if a user has permission to edit a build definition he can change the secret.

In order to overcome these two disadvantages I have created a build/release task that can be used to have a single instance of a secret (per team project) and that can be used to pass secrets to tasks.