February 2014 – Jasper Gilhuis

February 28, 2014July 17, 2014

Post a TFS Team Room Message from Visual Studio Release Management

This is Part 3 in the series on Release Management + PowerShell + TFS TeamRoom API. In this post I am going to utilize the PowerShell Enabled TFS Team Room API logic from a Release Template in Visual Studio Release Management.

I will not cover a ‘usual’ flow that will release an application based on a Team Foundation Server build, if you like more information on this please check out my post covering that here: Release Management with InRelease

Or you can check out my Curation on Release Management here: Getting Started with Release Mangement

In Part 2 of this series I figured out all the PowerShell commands needed to post a message to the Team Room. Now let’s advance.

Visual Studio Release Management allows for creating custom tools. To create a Tool a Custom PowerShell Script can be used, so let’s make a script that can post the message. You can use the PowerShell ISE Editor to create this script.

A little clarification on the script. It has two parameters, TeamRoomMessage and TeamRoomName. I choose not to pass all the TFS configuration to the script, but if you want you can 🙂

After declaring the parameters, the module (Wrapper to the Team Room API) is imported. Then variables are set and the call to the Team Room is made passing the received parameters.

Creating the tool in Visual Studio Release Management is fairly easy. Most important part is adding the PowerShell script as a resource. On the Execution section we specify that the tool is a PowerShell command.

Our script needs two parameters and those need to be passed as arguments to the script. Mind that the parameters are qouted otherwise spaces in the message might break the script.

Having created the tool we need to create an Action to be able to add this to the Release Template. The creation of the Action is quite similar to the creation of the tool.

Having the Tool and the Action ready we can continue to create a very simple Release Path to post a message. The Release Path is using an existing stage (Development) and an existing environment (Development Environment). Acceptance and validation are both set to be automatic. This way no manual actions are required.

Now that we have a Release Path available, we need to create a Release Template. On the Deployment Sequence we drag our target server. Next in to Toolbox we browse to the Custom Section. In the section we can find our Custom Action. Drag this action to the Server surface. It lists the two parameters that our action needs, which now can be provided.

After saving, on the top menu there is the possibility to create a “New Release”, provide it a unique name and our Release Template is pre-selected.

Let go and start the release! After starting the release you will see the Release Progress. As acceptance was set to be automatic, that step is automatically passed. Next the Deploy step is executed, status is Pending.

After a little waiting (posting the message doesn’t take that long) this will transfer to Done.

For the Deploy step there are details available. You can review these by clicking the ‘…’ button. The Deployment Log screen will be shown.

Through the View Log button we can see the log that is created during our ‘Add TeamRoomMessage’ action. The log message contains the output generated in our PowerShell Script. As we can see below it says our message is successfully posted!

The only place to find out if that’s true is to head over to our Team Room and see for our self! As expected the message is there!

As mentioned in the previous posts I promised to all the source code required for this complete series. You can download the source for this here: Release Management – Distribution.zip

Please note that this code was written for demo purposes only and is not intended to run on your production environment.

If you have any questions or remarks please feel free to leave a comment or contact me on twitter @jaspergilhuis

February 26, 2014July 17, 2014

Hidden Gems in TFS – Part 12 – Link to Versioned Item

This post is and addition to René van Osnabrugge’s great series of Hidden Gems in TFS. An overview of these Gems can be found at his blog “The Road to ALM” here:

http://roadtoalm.com/category/guidance/hidden-gems/

Just last week he showed me something that made me smile. His first response was “this has been around since… (I think we mentioned TFS 2005!!)

So what was it? We were talking on our Product Backlog, when he asked “Didn’t you create a document for that?” I replied “Yes I did!, it’s in source control, the path is in the workitem description”, something like $\Team Project\Folder\Folder\Document.docx.

He looked at me quite surprised and said “Did you know you can link to a Version Controled Item if you want?!”

I thought it was worth a little post 🙂

Guess I will link to Version Controlled Item from now!

February 23, 2014July 17, 2014

Encapsulate Team Room API calls with a PowerShell Commandlet

This post is Part 2 in the three part series on Release Management + PowerShell + TFS TeamRoom API. In this second post I am going to “PowerShell enable” the TeamRoomService API I created in part 1.

Because i am fairly new to PowerShelll, finding a way to achieve this took few searches and some reading on MSDN. Luckily there is more than enough on it! A good starter is here: http://msdn.microsoft.com/en-us/library/dd878294(v=vs.85).aspx

I decided to build from the PSCmdLet functionality while I wanted to preserve properties (remember the TFSURL, TFS UserName and TFS Password for the service?) between possible multiple TeamRoom calls. This saves typing verbose parameters over and over again. To preserve the settings we need to utilize the session state and are therefor required inheriting from the PSCmdLet class.

I decided to create a custom baseclass (PSCmdletBase) to be able to use in the actual Command Lets (Add, Find, Get, Remove). The base class checks if the required parameters are supplied.

Now let’s go create the CommandLet for posting a message. The class will inherit from the PSCmdLetbase. It has two mandatory properties defined. One for the message the other for the Team Room name.

The main method is quite simple, because the TeamRoomService previously created contains all the logic. Below an instance is created, the properties are provided, and the PostMessage method is called.

Having this compiled into a DLL we are ready to get to use it from the PowerShell commandline. Again this took some reading, I started on this page http://msdn.microsoft.com/en-us/library/dd878310(v=vs.85).aspx. Browsing a little further I came across this page http://msdn.microsoft.com/en-us/library/dd901839(v=vs.85).aspx. It shows us that we can import a .DLL as a module. Let give that a try.

First open a PowerShell Command window (running as Administrator). Mind that executing command from the PowerShell Console might require additional execution permissions. Please Read about them here http://go.microsoft.com/fwlink/?LinkID=135170.

For my demo purposes I set my PowerShell to Unrestricted mode.

Now let’s provide the command to import the module. If all goes well (no visual feedback) its successful. Note I am importing directly from my project output directory.

Now we should be able to call the CommandLet’s “Add-TeamRoomMessage” method. There are several ways of calling it. Remember that we first need to set the required variables! (I intentionally *** my password, it will be typed in plain text).

Now we are ready to use the CommandLet. We pass the TeamRoom and Message parameters to the command directly and hit enter.

We receive feedback hat we succesfully posted the message with ID 1242.

Now let’s browse to the TeamRoom to see our message! Yes, there it is!

This wraps up part two of this series! In the next and last part of this series we will dive into Visual Studio Release Management to allow us to post the message from there!

Note: The source code will be posted as a complete download with the next post so you get a full working solution.

February 18, 2014July 17, 2014

Utilize the TFS Team Room REST API

Here we go, part 1 of the announced series on Release Management + PowerShell + TFS TeamRoom API!

Based on the publicly available information in Brian Harry’s post on the Team Rooms API (http://blogs.msdn.com/b/bharry/archive/2013/07/22/rest-api-for-team-rooms.aspx) I decided that I wanted to add messages from Release Management to a particular Team Room.

Disclaimer: The Team Room API is subject to change, this might therefor not work in the future, and this code is just intended for demo purposes, so if you reuse it is at your own risk.

To get started I wanted a quick and easy way to be calling the Team Room API for this I created a service application to encapsulate the Team Room API calls. I had to figure out what the suggested route was to actually talk to the REST API. Popular REST frameworks, encapsulating the actual JSON plumbing, seem to be RestSharp (http://restsharp.org/) and NewtonSoft JSON (http://www.nuget.org/packages/newtonsoft.json/). Both can be included in your solution as NuGet packages.

Wanting to post a message I needed a TeamRoomService. This service needs a method, LoadTeamRooms(). This method uses the RestClient Object to call the Team Room API. While using the API the Team Project needs to enable Alternate Credentials. See the following URLS for more information on the neccesarry actions to enable this.

http://blogs.msdn.com/b/buckh/archive/2013/01/07/how-to-connect-to-tf-service-without-a-prompt-for-liveid-credentials.aspx

http://social.msdn.microsoft.com/Forums/vstudio/en-US/96aa6738-6f01-4015-8c59-25215cc84897/enable-alternative-credentials–

The LoadTeamRooms method lists all Team Rooms available. As you can see it requires some parameters to be able to connect to TFS. JSONConvert is used to parse the received Team Room API results.

Using a Test Project I could easily get the properties from a configuration file. My TeamRoomService accepts the properties. The TeamRoomServiceGetTeamRooms() method gets the rooms. The results are then places in an object that allows me to access them more easily.

P1_CreateTeamRoomService — Create Team Room Service

Running the tests and adding some watches I could easily validate I was on my way!

Being able to get the available Team Rooms I wanted to be able to find a specific one, re-using my earlier code this was quite simple. Please note my unit test has an if that validates my findings on either on-premise TFS or Visual Studio Online TFS instances.

In both scenarios this enabled me to find a specific Team Room. Having found the Team Room ID, I was able to use the PostMessage method on the Team Room API.

This calls the Post Message method of my TeamRoomService. This method calls the Team Room API Service to post a message. When successful it returns the ID of the posted message.

So lets check the Team Room for our message! Voila there it is!

Having you walked through the basis of my components we are able to utilize the Team Room API to post a message. In the next part I will take you to the next phase encapsulate this TeamRoomService in a PowerShell Commandlet.

Note: The source code for this will be posted as a complete download with the latest post of this series so you get a full working solution at once!

February 12, 2014July 17, 2014

Blog Post Series announcement on Release Management + PowerShell + TFS TeamRoom API

In a new series of posts I will be getting more out of the combination of Visual Studio Release Management + PowerShell + TFS TeamRoom API. The series will consist out of 3 posts that wrap it all together.

First post will come shortly! Stay tuned!

Update 1: Posted part one on 18 februari 2014
Update 2: Posted part two on 23 februari 2014
Update 3: Posted part three on 28 februari 2014