Integrate VSTS with Youtrack

Youtrack is a great issue tracking tool. It's light weight and has very intuitive UI. These two features makes it a great tool for customer issue reporting. Bad part is, that it currently doesn't have any support for VSTS, so if you would like to update tickets from VSTS it doesn't provide any out of the box solution. However Youtrack has a very easy to use REST API which can used to build custom integration.

Update Youtrack ticket from VSTS

VSTS doesn't also provide any tools to integrate with Youtrack either, so to update tickets from VSTS, we need to use the REST API. VSTS has a "native" support for azure functions, so linking VSTS into azure function and implementing small function we can easily integrate these two great tools.

Create new Azure Function

First create an new Azure Function project (from Visual Studio) which provides basic building blocks for our integration. By default Azure Function refers Newtonsoft.Json 9.0, which is too old version for our use. Add Newtonsoft.Json version 10.2 Nuget package and YouTrackSharp package (which requires at least version 10 from Newtonsoft.Json).

YouTrackSharp provides some very easy to use functions to interact with Youtrack REST API. It's a much faster way to implement REST calls than by coding them manually.

Create permanent token from Youtrack

Connection to Youtrack is done with BearerTokenConnection class, with this class we can use permanent token to login into Youtrack and it's a much better way than using our own user-name and password (which we don't want to check in into version control).

From Youtrack, click Update personal... link from own profile page to get into authentication page
From Authentication page, switch to Authencation tab and click New token... button

Code that function

After creating a connection with BearerTokenConnection we can call CreateIssueService method to retrieve a service which provides methods to update, delete and create new tickets.

var connection = new BearerTokenConnection("","perm:...");
var issueService = connection.CreateIssuesService();
With issue service we can iterate all the tickets we want to by providing Youtrack query as a string parameter:
foreach(var issue in await issueService.GetIssues("State: {Waiting for deployment}"))
     await issueService.ApplyCommand(issue.Id, "assigned to me");
Updating issue is done with ApplyCommand call.

Full example code to update all Waiting for deployment tickets into Deployed state.
public static class Function1
        public static async Task<HttpResponseMessage> Run([HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)]HttpRequestMessage req, TraceWriter log)
   var connection = new BearerTokenConnection("","perm:...");
            var issueService = connection.CreateIssuesService();
    foreach(var issue in await issueService.GetIssues("State {Waiting for deployment}"))
           await issueService.ApplyCommand(issue.Id, "Deployed");
    return req.CreateResponse(HttpStatusCode.OK);

Call Azure Function from VSTS

To call a Azure Function from VSTS, we need to add a new agentless phase to our release definition

Agentless phase can contain a Azure Function call which has only two mandatory settings.
1) Set Azure Function url with /api/ChangeYoutrackStatusToDeployed route
2) Add function key (which is created in Azure Portal)

Now when the release definition is run, VSTS calls our Azure Function, which updates all the "Waiting for Deployment" tickets into "Deployed" state.

Connect Azure Key Vault into Visual Studio Team Services

Deployment process usually contains secrets like passwords, usernames and urls. Commonly these secrets are put into CI build configuration, but there is an better option, at least if you are using Visual Studio Team Services.

Azure Key Vault

Image result for azure key vault

Azure Key Vault is an Azure service which can store your secrets safely. Key Vault has multiple advantages. For example you can group secrets into collection and give permissions for that collection. Changing passwords etc. is easier, because they are hold in one place.

Visual Studio Team Services can be connected to Azure Key Vault and it can use all the secrets needed for deployment.

First Create Azure Key Vault

Start by creating a new key vault into Azure and add secrets which are used in deployment

Second Connect VSTS into Key Vault

Log into Visual Studio Team Services and click Library link. Add new variable group and toggle "Link secrets from Azure key vault as variables". Toggling that will show options to select Azure subscription and key vault. Remember to save settings from top right.

Key Vault variables are used with syntax $(variable_name). For example Powershell task would look like this (don't mind about caps in names, I just masked some info away from it): 

What's really wrong with VSTS (Visual Studio Team Services)

First I have to say, that I use VSTS daily and I don't hate it. It has really cool features like great support for deployment options. However there are few big things that really screws the whole user experience. I hope raising these problems will push the development into right track.

My build definitions

SHOW ME THE BUILDS | image tagged in angry homer | made w/ Imgflip meme maker

When you click a huge Builds link from top navigation bar. What would you think its going to show you? Builds, what is currently under build, build history, build statistics etc., but no. What it shows you is an unbelievably list of build definitions. Yes, your build definitions. Worst part is that if someone else triggers a build, it's not shown in this page

Release is not a deployment

VSTS have split things into three big categories. Build, release and deployment. Build and release is  split into build definition and release definition. The funny thing is that release definition defines where your software is deployed. 
- Deployment settings are defined in release definition, but release is not a deployment. Why don't just create a deployment definition?
- When you click that huge Releases link from top menu, you are taken into page which shows topic "All release definitions" and smaller topic "Releases"(???) and under that is list of releases.

I understand the separation between release and deployment, but what really boggers me here is the way how release and deployment are coupled. They are not independent like build and release are, but they are not coupled totally.

How to design complex UI

RELEASE & DEPLOY | image tagged in big red button | made w/ Imgflip meme maker

I will go through one more example to summaries what is really wrong with VSTS. Creating new release, and deploy that into test/prod environment. This should be like number one feature in VSTS. There should be big red button with text RELEASE AND DEPLOY, which does this. Well it's surprisingly hard. 

First click Build And Release. (1)
It shows that useless Builds page. Click Releases (2)

Click (3) ... button next to release definition name.
Click (4) + Release

When dialog opens, click (5) Release.

So 5 clicks, two page loads and one dialog to create a new release & deployment. It might not sound much, but when all the major features are hidden like this, its starts to frustrate.

Current state of .NET - II

About year I go, I published blog post about current state of .NET and I think it's time to review what has been done and where we are going now.


Latest .NET version is 4.7.1. Windows 10 has 4.7.1 pre-installed after version 1709 (aka creators update) which was released in October 17, 2017.


Latest ASP.NET version is a 4.6 which was released in July 20, 2015. ASP.NET has moved into ASP.NET Core and there is no new version in sight for ASP.NET. All the development work is done into ASP.NET Core.

Latest ASP.NET Core version is 2.0.3 and it was published in November 29, 2017.


Last good old ASP.NET MVC version was published in February 2, 2015. After that is all ASP.NET Core MVC. Latest ASP.NET Core MVC version is 2.0.2 and its available as Nuget package


C# is currently running at version 7.2 which was released with Visual Studio 2017 version 15.5. Microsoft has moved into more frequent release cycle with C#. There is also roadmap for version 8.0 and you can view it from Github.
Latest VB.NET version is 15 and it was released along with Visual Studio 2017.

Image by

Link Netatmo product into Slack

Lately I have been working with Netatmo API. I own the in-house Netatmo weather station with one extra module. The extra module is located in our storage room where we have also water pipe. I have set-up an alarm for my phone which will send me notification if temperature drops below 4 Celsius. This all works nicely, but I wanted to tinker with my weather station and add new way to interact with it.

We use Slack in our company and I have a Slack window open all day. Why wouldn't I integrate Netatmo product into Slack!

I started this project from Netatmo side. They offer nice API for data, but I wanted .NET SDK to access it more easily. I couldn't find any suitable so I decided to created my own.

First I created data classes from their swagger documentation with Autorest. Then I removed Autorest ready made client because it couldn't handle authentication. Next I implemented authentication into NetatmoAuth class using Restsharp rest client library. Restsharp brings few nice things which helps working with rest apis, but on the other hand it has few weirdness, like the default serialization is done in xml if server doesn't return json content type.

After clearing default client and implementing authentication I created a new client class which handles login and wraps rest API into nice .NET SDK.

Next I will create Microsoft Bot Framework App which integrates into Slack. This bot app will fetch weather data form Netatmo station and provide it into Slack channel.

Feel free to contribute into NetatmoCore project and implement methods for your devices, like thermostats and security cameras.

Setting Up Build Into Visual Studio Team Services

Visual Studio Team Services (VSTS) offers a nice set of tools for CI builds. In this blog post I'm going to show you how to setup a automatically triggered build environment for basic ASP.NET MVC web project. CI builds aren't restricted for ASP.NET web sites only, but I think that type of project is one of the most common.

Setting up build

Log into VSTS site and select project from dashboard, or create new one. I'm creating a new project in this post
Creating new project will take a while, but after it's completed you have a version control system and work mangement task board setup. Next link the given Git url into Visual Studio by finding the project from Visual Studio Team Explorer (Click Manage Connections in Visual Studio Team Explorer and log in with same account as the VSTS project was made).

Next create a new ASP.NET MVC solution or use existing one to get something to use in builds:

Commit your code into source control and push master branch.

Check Code > Files tab to ensure that you have your code in source control.

Creating build definition

Navigate into Build & Releases > Build tab and create a new defition.
Select ASP.NET (PREVIEW) project type to get a nice set of ready made build steps.

On the left side are build steps which are executed on every build. Right side contains parameters for each build step. Select a Hosted VS2017 into Default agent queue selection. This means that our build definition is handled by Visual Studio 2017 type of build agents.

Next link your Visual Studio solution by clicking ... button next to path to solution or packages.config textbox. 

Finally remove the Test Assemblies build step by right clicking the task and selecting "Remove selected tasks". Click Save & queue button from top right and a new build should start.

Click blue build number to navigate into build log:

Build succeeded! You can download built items from Artifacts link.

Setting up build trigger

Next let's edit our build definition, and add new build trigger which builds our solution when new code gets committed in. Click Build & Releases tab and start build editor (click ... button next to build definition name and select Edit...).
Navigate into triggers tab and Enable "Continuous integration" trigger
Now our build is run every time something is committed into master branch. VSTS supports also scheduled triggers and custom triggering via Rest API (for example:

Visual Studio Team Services Use Guide

Visual Studio Team Services (VSTS) formerly known as Visual Studio Online is a pack of CI related services built into cloud. VSTS offers four main services:
1) Work item tracking
2) Code related services
3) Testing services
4) Build and releases

On my following blog posts I'm going to focus two of these: Code related services and build & releases.

How to start?

VSTS is included in most of MSDN subscriptions, so basically if you are working for a employer, you can start using VSTS services immeaditely. Log into and start by creating a new project. VSTS got easy tutorials to follow, so I won't repeat those here.

Basic usage

Dashboards is your start view when you log into VSTS. This view is customizable, but I usually just skip it and navigate into useful pages.

Code is view into your source control system. VSTS supports two different kind of version control systems: GIT and TFVS (TFS). If you are used to use Subversion, then TFS is your pick of choice, but otherwise I would recommend to start using GIT.

VSTS navigation is mainly done from top blue bar

Under main navbar is a second navbar which contains sub-links for each page. Under code page the sub links are following:
Files is a repository browser
Commits is a version history view
Pushes contains list of push from clients
Branches has a nice list of public branches from from master (in GIT)
Tags... well it contains just list of done tags
Pull requests contains list of active build request, but its also a place to do your own pull request (if not done from Visual Studio).
Sub links in code page

Build & Releases tab contains all the needed items for CI builds and deployments.
Builds contains a list of created build definitions (and a button to do new one)
Releases contains list of release definitions and way to navigate actual done releases
Library and Task Groups can be skipped at this point.
Deployment Group is just a higher level for managing releases and buids.

Now we have covered the basics of navigation. Some of the VSTS features can be also used from Visual Studio itself. Visual Studio feature is called Team Explorer. You can do pull requests, trigger builds and manage work items without leaving the Visual Studio.


At the writing moment, VSTS pricing looked liked this:
First 5 users: Free 
Users 6 through 10: €5.06 each 
Users 11 through 100: €6.747 each 
Users 101 through 1000: €5.06 each 
Users 1,001 and above: €3.374 each 

Prices per month

Basically you can start for free and after 5 users pricing is ~5€ each user (in west europe). Test management, build & releases and cloud load testing are separately priced. For example VSTS build time is free under 240 minutes, but extra time costs. More details about pricing can be found from Azure pricing page

On next topic I will dig into VSTS build system and give a tutorial how to setup an ASP.NET CI build.