Deploy Azure Web Apps with Parameterization

I have blogged before about how to deploy an Azure Web App using the new build system in TFS 2015/Visual Studio Team Services. In addition to configure an Azure service endpoint, it is really only a matter of using the built-in Azure Web App Deployment task.

However, in many cases I have decided not to use this task myself since it has been lacking a key feature: Applying deployment parameters using the SetParameter.xml file.

As I have mentioned a gazillion times, building your binaries once and only once is a key principle when implementing continuous delivery. If you are using web deploy for deploying web applications (and you should), you must then use Web Deploy parameters to apply the correct configuration values at deployment time.

Under the hood the Azure Web App Deployment task uses the Publish-AzureWebsiteProject cmdlet that uses web deploy to publish a web deploy package to Microsoft Azure. Up until recently, this cmdlet did not support web deploy parameters, the only thing that you could substitute was the connecting string, like so:

Publish-AzureWebsiteProject -Name site1 -Package package.zip -ConnectionString @{ DefaultConnection = "my connection string" }

However, it is actually possible to specify the path to the SetParameter.xml file that is generated together with the web deploy package. To do this, you can use the –SetParametersFile parameter, like so:

Publish-AzureWebsiteProject -Name Site1 -Package package.zip -SetParametersFile package.SetParameters.xml

When using the Azure Web App Deployment task, there is no separate parameter for this but you can use the Additional Arguments parameter to pass this information in:

Note: In this case, I am using the Azure Web App Deployment task as part of a release definition in Visual Studio Release Management, but you can also use it in a regular build definition.

This will apply the parameter values defined in the QBox.Web.SetParameters.xml file when deploying the package to the Azure Web App.

If you are interested, here is the pull request that implemented support for SetParameters files: https://github.com/Azure/azure-powershell/pull/316

Downloading Build Artifacts in TFS Build vNext

Since a couple of months back, Microsoft new Release Management service is available in public preview in Visual Studio Team Services. According to the current time plan, it will be released for on-premise TFS in the next update (Update 2).

Using a tool like release management allows you to implement a deployment pipeline by grabbing the binaries and any other artifacts from your release build, and then deploy them across different environments with the proper configuration and approval workflow. Building your binaries once and only once is a fundamental principal of implementing continuous delivery, too much can go wrong if you build your application every time you deploy it into a new environment.

However, sometimes you might not have the opportunity to setup a release management tool like VSTS or Octopus Deploy, but you still want to be able to build your binaries once and deploy them. Well, you can still implement your deployment using TFS Build, but instead of building your source code during every build we download the artifacts from another build that already has completed.

Let’s look at how we can implement this using PowerShell and the REST API in TFS/VSTS.In this sample we will execute this script as part of a TFS build, in order to create a “poor mans” deployment pipeline. If you want to use the script outside of TFS Build, you need to replace some environment variables that are used in the script below.

Downloading Build Artifacts using PowerShell and the REST API

First of all, to learn about the REST API and other ways to integrate and extend Visual Studio, TFS and Visual Studio Team Services, take a look at https://www.visualstudio.com/integrate. This is a great landing page that aggregate a lot of information about extensibility.

Here is a PowerShell script that implements this functionality, as well as a few other things that is handy if you implement a deployment pipeline from a build definition.

[CmdletBinding()]

param(
    [Parameter(Mandatory=$True)]
    [string]$buildDefinitionName,
    [Parameter()]
    [string]$artifactDestinationFolder = $Env:BUILD_STAGINGDIRECTORY,
    [Parameter()]
    [switch]$appendBuildNumberVersion = $false
)
    Write-Verbose -Verbose ('buildDefinitionName: ' + $buildDefinitionName)
    Write-Verbose -Verbose ('artifactDestinationFolder: ' + $artifactDestinationFolder)
    Write-Verbose -Verbose ('appendBuildNumberVersion: ' + $appendBuildNumberVersion)

    $tfsUrl = $Env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI + $Env:SYSTEM_TEAMPROJECT

    $buildDefinitions = Invoke-RestMethod -Uri ($tfsURL + '/_apis/build/definitions?api-version=2.0&name=' + $buildDefinitionName) -Method GET -UseDefaultCredentials
    $buildDefinitionId = ($buildDefinitions.value).id;
    
    $tfsGetLatestCompletedBuildUrl = $tfsUrl + '/_apis/build/builds?definitions=' + $buildDefinitionId + '&statusFilter=completed&resultFilter=succeeded&$top=1&api-version=2.0'

    $builds = Invoke-RestMethod -Uri $tfsGetLatestCompletedBuildUrl -Method GET -UseDefaultCredentials
    $buildId = ($builds.value).id;

    if( $appendBuildNumberVersion)
    {
        $buildNumber = ($builds.value).buildNumber
        $versionRegex = "d+.d+.d+.d+"

        # Get and validate the version data
        $versionData = [regex]::matches($buildNumber,$versionRegex)
        switch($versionData.Count)
        {
           0        
              { 
                 Write-Error "Could not find version number data in $buildNumber."
                 exit 1
              }
           1 {}
           default 
              { 
                 Write-Warning "Found more than instance of version data in buildNumber." 
                 Write-Warning "Will assume first instance is version."
              }
        }
        $buildVersionNumber = $versionData[0]
        $newBuildNumber =  $Env:BUILD_BUILDNUMBER + $buildVersionNumber
        Write-Verbose -Verbose "Version: $newBuildNumber"
        Write-Verbose -Verbose "##vso[build.updatebuildnumber]$newBuildNumber"
    }

    $dropArchiveDestination = Join-path $artifactDestinationFolder "drop.zip"


    #build URI for buildNr
    $buildArtifactsURI = $tfsURL + '/_apis/build/builds/' + $buildId + '/artifacts?api-version=2.0'
    
    #get artifact downloadPath
    $artifactURI = (Invoke-RestMethod -Uri $buildArtifactsURI -Method GET -UseDefaultCredentials).Value.Resource.downloadUrl

    #download ZIP
    Invoke-WebRequest -uri $artifactURI -OutFile $dropArchiveDestination -UseDefaultCredentials 

    #unzip
    Add-Type -assembly 'system.io.compression.filesystem'
    [io.compression.zipfile]::ExtractToDirectory($dropArchiveDestination, $artifactDestinationFolder)

    Write-Verbose -Verbose ('Build artifacts extracted into ' + $Env:BUILD_STAGINGDIRECTORY)

This script accepts three parameters:

buildDefinitionName
This is a mandatory parameter where you can specify the name of the build definition from which you want to download the artifacts from. This script assumes that the build definition is located in the same team project as the build definition in which this script is running. If this is not the case, you need to add a parameter for the team project.

artifactsDestinationFolder
This is an optional parameter that let’s you specify the folder where the artifacts should be downloaded to. If you leave it empty, it will be downloaded to the staging directory of the build (BUILD_STAGINGDIRECTORY)

appendBuildNumberVersion
A switch that indicates if you want to append the version number of the linked build to the build number of the running build. Since you are actually releasing the build version that you are downloading artifacts from, it often makes sense to use this version number for the deployment build. The script will extract a 4 digit version (x.x.x.x) from the build number and then append it to the build number of the running build.

As an example, if the latest release build has the build number MyApplication-1.2.3.4, the build will extract 1.2.3.4 and append this to the end of the build number of the running build.

Running the script in TFS Build

Running a PowerShell script in TFS Build is really easy, but I’ll include it here anyway. Typically you will run this script in the beginning of a build in order to get the build artifacts, and then add the tasks related to deploying the artifacts in whatever way that fits.

Add the script to source control and then add a PowerShell task to the build definition and select the script from the repository. Then specify the parameters of the tasks in the argument field

Here is a sample argument:

-buildDefinitionName MyApplication.Release –appendBuildNumberVersion

Where MyApplication.Release is the name of the build definition that have produced the build artifacts that we want to release.

Running this script as part of the build will not download the artifacts from the latest successful build of the linked build definition and place them in the staging directory. In addition it will append the version number of the linked build (x.x.x.x) to the end of the running build.

NB: You need to consider where to place this script. Often you’ll want to put this script together with the application that you are deploying, so that they can change and version together.

Hope you will find this script useful, le me know if you have any issues with it!

Happy building!

PS: If you want to learn more about implementing Continuous Delivery using Visual Studio Team Services and TFS, grab a copy of my and Mathias Olausson’s latest book “Continuous Delivery with Visual Studio ALM 2015”

Microsoft Developer Roadshow Sweden with Active Solution

This december we at Active Solution team up with Microsoft Sweden to deliver a full day of Azure and Internet of Things (IoT) goodness in 4 different cities around Sweden:

Malmö – Dec 1
Göteborg – Dec 2
Umeå – Dec 8
Stockholm – Dec 9

This is a unique opportunity for devlopers, startups and students that want to learn more about what Microsoft Azure has to offer and how you can implement IoT solutions together with Azure.

The day will be a mixture of sessions, discussions and hands-on labs where you will have the chance to try out these technologies in practice, just bring your Windows 10 laptop with Visual Studio 2015 and the Azure SDK installed,
and make sure that you also have an active Azure subscription (an evaluation subscription will be fine)

From Active Solution, myself and Robert Folkesson will host the second part of the day, where we will guide you through the hands-on labs.

Read more and sign up for the event at http://devroadshow.net/

Image result for microsoft azure

Hope to see you there!

New Book – Continuous Delivery with Visual Studio ALM 2015

With today’s announcement at Microsoft Connect() about the public preview of the next generation of Visual Studio Release Management, it is also time to announce the (imminent) release of a new book that covers among other things this new version of RM.

Me and my fellow ALM MVP Mathias Olausson have been working hard during the last 6 months on this book, using early alpha and beta versions of this brand new version of Visual Studio Release Management. Writing about a changing platform can be rather challenging, and our publisher (Apress) have been very patient with us regarding delays and late changes!

About the book

The book is titled Continuous Delivery with Visual Studio ALM 2015 and is aiming to be a more practical complement to Jez Humble’s seminal Continous Delivery book with a heavy focus of course on how to implement these processes using the Visual Studio ALM platform.

The book discusses the principles and practices around continuous delivery and continuous deployment, including release planning, source control management, build and test automation and deployment pipelines. The book uses a fictive sample application that we use throughout the book as a concrete example on how to go about to implement a continuous delivery workflow on a real application.

We hope that you will find this book useful and valuable!

Abstract

This book is the authoritative source on implementing Continuous Delivery practices using Microsoft’s Visual Studio and TFS 2015. Microsoft MVP authors Mathias Olausson and Jakob Ehn translate the theory behind this methodology and show step by step how to implement Continuous Delivery in a real world environment.

Building good software is challenging. Building high-quality software on a tight schedule can be close to impossible. Continuous Delivery is an agile and iterative technique that enables developers to deliver solid, working software in every iteration. Continuous delivery practices help IT organizations reduce risk and potentially become as nimble, agile, and innovative as startups.

In this book, you’ll learn:

What Continuous Delivery is and how to use it to create better software more efficiently using Visual Studio 2015
How to use Team Foundation Server 2015 and Visual Studio Online to plan, design, and implement powerful and reliable deployment pipelines
Detailed step-by-step instructions for implementing Continuous Delivery on a real project

Table of Content

Chapter 1: Introduction to Continuous Delivery
Chapter 2: Overview of Visual Studio 2015 ALM
Chapter 3: Designing an Application for Continuous Delivery
Chapter 4: Managing the Release Process
Chapter 5: Source Control Management
Chapter 6: PowerShell for Deployment
Chapter 7: Build Automation
Chapter 8: Managing Code Quality
Chapter 9: Continuous Testing
Chapter 10: Building a Deployment Pipeline
Chapter 11: Measure and Learn

Microsoft Announces Next Generation of Visual Studio Release Management

Today at the Microsoft Connect() event, Microsoft announced the public preview of the brand new version of Visual Studio Release Management. The public preview is available on Visual Studio Team Services (a.k.a. Visual Studio Online, in case you missed that announcement! :-)), and will debut on premise later in 2016.

So, what’s this new version about? Let’s summarize some of the major features about it:

Web Based

The existing version of Visual Studio Release Management, that was originally acquired from InCycle back in 2013, uses a standalone WPF client for authoring, triggering and tracking releases. It always felt a bit awkward and wasn’t really integrated with the rest of TFS. The new version is completely rewritten to be a web based experience and is part of the web access, as a new “Release” tab.

From this hub you can author release definitions, manage approval workflows and trigger and track releases.

Shared Infrastructure with TFS Build

With the new build system in TFS 2015, Microsoft already has a great automation platform that is scriptable, cross platform and easy to deploy and configure. So it makes sense that the new version of Visual Studio Release Management is build upon the same platform. So the build agent that is used for running builds can also be used for executing releases.

It also means that all the new build tasks that are available in TFS Build 2015 and also be used as part of a release pipeline.

Cross Platform Support

As mentioned above, since the same agent is used for releases, it means that we can also run them on Linux and OS/X since these are supported platforms. There are many tasks out of the box for doing cross platform deployment, including Chef and Docker.

Track Releases across Environments

The new web UI makes it easy to get an overview of the status of your existing environments, and which version of which application that is currently deployed. In the example below we can see that the new release of the “QuizBox” application has been deployed to Dev and QA, has gone through automated and manual acceptance tests, and is currently being deployed to the staging slot of the production environment.

Configuration Management

One of the biggest challenges with doing staged deployments is the configuration management. The different environment often have different configuration settings, things like connection strings, account names and passwords. In Visual Studio Release Management vNext these configuration variables can be authored either on the environment level or on the release definition level, where it applies to all environments.

We can easily compare the configuration variables across our environments, as shown below.

Live Release Log Output

As with the new build system in TFS 2015, VSRM vNext gives you excellent real time logging from the release agent, as the release is executing.

Release Approval

Every environment in the release pipeline can trigger approvals, either before the deployment starts or after. For example, before we want to deploy a new version of an application to the QA environment, the QA team should be able to approve it to make sure that the environment is ready.

Below you can see a release that has a pending approval. Every approver that should take action will receive a notification email with a link to this page.

Do you want to learn more?

For the last 6 months, me and my fellow ALM MVP and good friend Mathias Olausson have been busy working on a book that covers among other things this new version of Visual Studio Release Management. The title of the book is Continuous Delivery with Visual Studio ALM 2015, and covers how the process of continuous delivery can be implemented using the Visual Studio 2015 ALM tool suite.

I will write a separate blog post about the book, but here is the description from Amazon:

In this book, you’ll learn:

What Continuous Delivery is and how to use it to create better software more efficiently using Visual Studio 2015
How to use Team Foundation Server 2015 and Visual Studio Online to plan, design, and implement powerful and reliable deployment pipelines
Detailed step-by-step instructions for implementing Continuous Delivery on a real project

You can find the book at http://www.amazon.com/Continuous-Delivery-Visual-Studio-2015/dp/1484212738.

We hope that you will find it valuable!

Performance Tests for Azure Web Apps

Anyone that has been involved with setting up the infrastructure that is needed to perform on premise load testing of a realistic number of users knows how much work that is to both setup and to maintain. With Visual Studio Ultimate/Enterprise you needed to create a test rig by creating multiple machines and then installing a test controller and test agents on all the machines and configure them to talk to each other.

Another aspect of if is that the typical team don’t run load tests of their applications on a regular basis, instead it is done during certain periods or sprints during the lifecycle of the project. So the rest of time those machines aren’t used for anything, so basically they are just using up your resources.

Cloud Load Testing

With the introduction of Cloud Load Testing, that is part of Visual Studio Online, Microsoft added the possibility to use Azure for generating the load for your tests. This means that you no longer have to setup or configure any agents at all, you only need to specify the type of load that you want, such as the number of users and for how long the test should run. This makes it incredibly easy to run load tests, and you only pay for the resources that you use. You can even use it to test internal application running behind a firewall.

So, this feature has been around for a couple of years, but there has always been a problem with discoverability due to it being available only from inside the Visual Studio Online portal. So for teams that uses Azure for running web apps but are not using Visual Studio Online for their development, they would most likely never see or use this feature.

But back in September Microsoft announced the public preview of perfomance testing Azure Web Apps, fully integrated in the Azure Portal. It still needs a connection to a Visual Studio Online account, but as you will see this can easily be done as part of setting up the first performance test.

Let’s take a quick look at how to create and run a performance test for an Azure Web App.

Azure Web App Performance Test

The new Performance Test functionality is available in the Tools blade for your web app, so go ahead and click that.

The first time you do this, you will be informed that you need to either create a Visual Studio Account or link to an existing one. Here I will create a new one called jakobperformance.

Note that:

It must have a unique name since this will end up as <accountname>.visualstudio.com)
It does not mean that you have to use this account (or any other VSO account for that matter) for your development.

Currently the location must be set to South Central US, this is most likely only the case during the public preview.

When you do this, you will receive a nice little email from Microsoft that includes a lot of links to more information
about how to get started with cloud load testing.

A simple thing really, but things like this can really make a difference when you are trying a new technology for the first time.

So, once we have create or linked the VSO account we can go ahead and create a new performance test. Here is the information that you need to supply:

URL
The public URL that the performance test should hit. It will be default be set to the URL of the current Azure Web App, but you can change this.

Name
The name of this particular test run. As you will see, all test runs are stored and available in the Performance Test blade of your Azure Web App, so give it a descriptive name.

Generate Load From
Here you select from which region that the load should be generated from. Select the one that most closely represent the origin of your users.

User Load
The number of users that should hit your site. While this feature is in public preview you don’t have to pay for running these load tests, but there will some limits in how much load you can generate. You can contact Microsoft if you need to increase this limit during the preview period.

Duration (Minutes)
Specifies for how long (in minutes) that the load test should run

Once this is filled out, hit Run Test to start the load test. This will queue the performance test and then start spinning up the necessary resources in Azure for running the load test.

Clicking on the test run, you will see information start to come in after a short period of time, showing the number of requests generated and some key performance characteristics of how your application behaves under pressure.

Of course, this type of load testing doesn’t cover all you need in terms of creating realistic user load, but it is a great way to quickly hit some key pages of your site and see how it behaves. then you can move on and author more complex load tests using Visual Studio Enterprise, and run them using Azure as well.

Go ahead and try it out for yourself, it couldn’t be easier and during the public preview it is free of charge!

10 Features in Team Foundation Server that you maybe didn’t know about

I often talk to different teams about how they work with Team Foundation Server or Visual Studio Online. I get a lot of questions about different features, and some of them tend to come up more often than other. So here is a list of 10 features in TFS that I get questions about regularly or that I have noticed a lot of teams don’t know about. It is by no means exhaustive, and it is a mixture of smaller and larger features, but hopefully you will find something here that you didn’t know about before.

1. Associate Work Items in Git commits from any client

Associating work items to your changesets in TFS have always been one of the more powerful features. Not in itself, but in the traceability that this gives us.
Without this, we would have to rely on check-in comments from the developers to understand the reason for a particular change, not always easy when you look at changes that were done a few years back!

When using Git repos in TFS, and you use the Git integration in Visual Studio you have the same functionality that lets you associate a work item to a commit, either by using a work item query or by specifying a work item ID.

But a lot of developers like to use other Git tooling, such as Git Extensions, SourceTree or the command line. And then we have the teams that work on other platforms, perhaps developing iOS apps but store their source code in a Git repo in TFS. They obviously can’t use Visual Studio for committing their changes to TFS.

To associate a commit with a work item in these scenarios, you can simply enter the ID of the work item with a # in front of it as part of the commit message:

git commit –a –m “Optimized query processing #4321”

Here we associate this commit with the work item with ID 4321. Note that since Git commits are local, the association won’t actually be done until the commit has been pushed to the server. TFS processes git commits for work item association asynchronously, so it could potentially take a short moment before the association is done.

2. Batch update work items from the Web Access

Excel has always been a great tool for updating multiple work items in TFS. But over the years the web access in TFS has become so much better so that most people do all their work related to work item management there. And unfortunately, it is not possible to export work item queries to Excel as easily from the web as it is from Visual Studio.

But, we can update multiple work items in TFS web access as well. These features have gradually been added to Visual Studio Online and is now part of TFS 2015 as well.

From the product backlog view, we can select multiple work items and the perform different operations on them, as shown below:

There are a few shortcut operations for very common tasks such as moving multiple backlog items to a iteration, or assigning them to a team member.
But then you have the Edit selected work item(s) that allows us to set any fields to a new value in one operation.

You can also do this from the sprint backlog and from the result list of a work item query.

3. Edit and commit source files in your web browser

Working with source code is of course done best from a development IDE such as Visual Studio. But sometimes it can be very convenient to change a file straight from the web access, and you can! Maybe you find a configuration error when logged on a staging environment where you do not have access to Visual Studio. Then you can just browse to the file in source control and change it using the Edit button:

After making the changes, you can add a meaning commit message and commit the change back to TFS. When using Git, you can even commit it to a new branch.

4. Bring in your stakeholders to the team using the free Stakeholder license

Normally, every team member that accesses TFS and reads or writes information to it (source code, work items etc) need to have a Client Access License (CAL). For the development team this is usually not a problem, often they already have a Visual Studio with MSDN subscription in which a TFS CAL is included. What often cause some friction is when the team try to involve the stakeholders. Stakeholders often include people who just want to track progress or file a bug or a suggestion occasionally. Buying a CAl for every person in this role usually ends up being way to expensive and not really worth it.

In TFS 2013 Update 4 this was changed, from that point people with a stakeholder license does not a CAL at all, they can access TFS for free. Buth they still have a limited experience, they can’t do everything that a normal team member can. Features that a stakeholder can use include:

Full read/write/create on all work items
Create, run and save (to “My Queries”) work item queries
View project and team home pages
Access to the backlog, including add and update (but no ability to reprioritize the work)
Ability to receive work item alerts

To learn more about the Stakeholder license, see https://msdn.microsoft.com/Library/vs/alm/work/connect/work-as-a-stakeholder

5. Protect your Git branches using branch policies

When using Team Foundation Version Control (TFVC) we have from the first version of TFS had the ability to use check-in policies for enforcing standards and policies of everything that is checked in to source control. We also have the ability to use Gated Builds, which allows us to make sure that a changeset is not checked in unless an associated build definition is executed successfully.

When Git was added to TFS back in 2013, there was no corresponding functionality available. But in TFS 2015 now, the team has added branch policies as a way to protect our branches from inadvertent or low quality commits. In the version control tab of the settings administration page you can select a branch from a Git repo and then apply branch policies. The image below shows the available branch policies.

Here we have enabled all three policies, which will enforce the following:

All commits in the master branch must be made using a pull request
The commits in the pull request must have associated work items
The pull request must be reviewed by at least two separate reviewers
The QBox.CI build must complete successfully before the pull request can be merged to the master branch

I really recommend that you start using these branch policies, they are an excellent way to enforce the standard and quality of the commits being made, and can help your team improve their process and help move towards being able to deliver value to your customers more frequently.

6. Using the @CurrentIteration in Work Item Queries

Work Item Queries are very useful for retrieving the status of your ongoing projects. The backlogs and boards are great in TFS for managing the sprints and requirements, but the ability to query on information across one ore more projects are pivotal. Work item queries are often used as reports and we can also create charts from them.

Very often, we are interested in information in the current sprint, for example how many open bug are there, how many requirements do we have that doesn’t have associated test cases and so on. Before TFS 2015, we had to write work item queries that referenced the current sprint directly, like so:

The problem with this was of course that as soon as the sprint ended and the next one started, we hade to update all these queries to reference the new iteration. Some people came up with smart work arounds, but it was still cumbersome.

Enter the @CurrentIteration token. This token will evaluate to the currently sprint which means we can define our queries once and they will continue to work for all upcoming sprints as well.

this token is unfortunately not yet available in Excel since it is not team-aware. Since iterations are configured per team, it is necessary to evaluate this token in the context of a team. Both the web access and Visual Studio have this context, but the Excel integration does not, yet.

Learn more about querying using this token at https://msdn.microsoft.com/en-us/Library/vs/alm/Work/track/query-by-date-or-current-iteration

7. Pin Important Information to the home page

The new homepage has been available since TFS 2012, and I still find that most teams does not use the possibility to pin important information to the homepage enough.
The homepage is perfect to show on a big screen in your team room, at least if you show relevant information on it.

We can pin the following items to the home page:

Work Item Queries
The tile will show the number of work items returned by the query . Focus on pinning queries where the these numbers are important and can trigger some activity. E.g. not the total number of backlog items, but for example the number of active bugs.
Build Definition
This tile shows a bar graph with the history of the last 30 builds. Gives a good visualization of how stable the builds are, if you see that builds fails every now and then you have a problem that needs to be investigated.
Source control
Shows the number of recent commits or changesets. Will let you know how much activity that is going on in the different repos
Charts
Charts can be created from work item queries and can also be pinned to the home page. Very useful for quickly give an overview of the status for a particular area

Here is an example where we have added a few items of each type

8. Query on Work Item Tags

Support for tagging was first implemented back in TFS 2012 Update 2. This allowed us to add multiple tags to work items and then filter backlogs and query results on these tags.
There was however a big thing missing and that was the ability to search for work items using tags.

This has been fixed since TFS 2013 Update 2, which means we can now create queries like this.

It is also possible to work with tags using Excel, this was another big thing missing from the start.

Unfortunately it is not yet possible to setup alerts on tags, you can vote on this feature on UserVoice here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6059328-use-tags-in-alerts

9. Select how you want to handle bugs

One of the most common questions I get when talking to teams that use TFS is how they should handle bugs. Some teams want to have the bugs on the backlog and treat them like requirements. Other teams want to treat them more like tasks, that is adding them to the corresponding user story or backlog item and use the task board to keep track of the bug.

The good think is that you can configure this per team now. On the team settings page, there is a section that lets you configure the behavior of bugs.

To learn more about controlling the behavior of bugs, see https://msdn.microsoft.com/Library/vs/alm/work/customize/show-bugs-on-backlog

10. Integrate with external or internal services using Service Hooks

Extensibility and integration are very important to Microsoft these days, and this is very clear when looking at the investments for TFS 2015 that included a bunch of work in this area. First of all Microsoft has added a proper REST API for accessing and updating most of the available artifacts in TFS, such as work items and builds. It uses OAuth 2.0 for authentication, which means it is based on open modern web standards and can be used from any client on any platform.

In addition to this, TFS 2015 also support Service Hooks. A service hook is basically a web endpoint that can be called when something happens, in this case in TFS. So for example, when a backlog item is created in TFS we might want to also create a card in Trello. Or when a new change is committed into source control, we might want to kick off a Jenkins build.

Here is a list of the services that are supported out of the box in TFS 2015:

And the list keeps growing, in Visual Studio Online there are already 7 more services offered, including AppVeyor, Bamboo and MyGet.

Note that the list contains one entry called Web Hooks. This is a general service configuration in which you can configure a HTTP POST endpoint that will receive messages for the events that you configure. The messages can be sent using JSON, MarkDown, HTML or text. This mean that you can also integrate with internal services, if they expose HTTP REST endpoints.

To learn more about service hooks, see https://www.visualstudio.com/en-us/integrate/get-started/service-hooks/create-subscription

Generate custom build numbers in TFS Build vNext

By now, many of you should have had the chance to at least play with the new build system that was released in TFS 2015 and Visual Studio Online. Here is an introductory post I wrote about it when it entered public preview back in January.

Doing the basic stuff is very easy using the new build system, especially if you compare it with the old one, which is now referred to as XAML builds. Creating and customizing build definitions is just a matter of adding the tasks that you want to use and configure them properly, everything is done using the web interface that is part of the TFS Web Access.

Build Number Format

There are (of course) still some things that are not completely obvious how to do. One of these things is how to generate a custom build number for a build. Every build definition has a build number format field where you can use some macros to dictate what the resulting build number should look like.

The build number format can contain a mix of text and macros, in the above example I have used some of the date macros to generate a build number that uses todays date plus an increment at the end.

Generating a custom build number

Sometimes though you will have the requirement to generate a completely custom build number, based on some external criteria that is not available using these macros.

This can be done, but as I mentioned before, it is not obvious! TFS Build contains a set of logging commands that can be used to generate output from a task /typically a script) that is generated in a way so that TFS Build will interpret this as a command and perform the corresponding action. Let’s look at some examples:

##vso[task.logissue type=error;sourcepath=someproject/controller.cs;linenumber=165;columnumber=14;code=150;]some error text here

This logging command can be used to log an error or a warning that will be added to the timeline of the current task. To generate this command, you can for exampleuse the following ‘PowerShell script:

Write-Verbose –Verbose “##vso[task.logissue type=error;sourcepath=someproject/controller.cs;linenumber=165;columnumber=14;code=150;]some error text here”

As you can see, there is a special format that is used for these commands: ##vso[command parameters]text. This format allows the build agent to pick up this command and process it.

Now, to generate a build number, we can use the task.setvariable command and set the build number, like so:

##vso[task.setvariable variable=build.buildnumber;]1.2.3.4

This will change the build number of the current build to 1.2.3.4. Of course, you would typically generate this value from some other source combined with some logic to end up with a unique build number.

You can find the full list of logging commands at https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md

AssociateRecentWorkItems Extension available for Visual Studio 2015

I finally got around to upgrading the Inmeta AssociateRecentWorkItems extension to support Visual Studio 2015. Several people have contacted me about this, sorry that it took so long!

About the extension

This extension makes it easy to associate multiple checkins with the same work items, as it shows a list of the recently associated work items from which you can easily associate one with the current pending changes.

Osiris AssociateRecentWorkItems VS2015

Associating work items

Note about the rebranding

At the same time, I rebranded this extension to use the Osiris brand. Osiris being the company that I originally worked, before it was acquired by Inmeta. Now I don’t work for Inmeta anymore, so me and my former colleague Terje Sandström decided to bring back the Osiris name and created a GitHub account for it called OsirisOS (OS for open source then…).

It’s available over at https://github.com/OsirisOS and currently contain one repo for the AssociateRecentWorkItems extension. Hopefully we will add more cool and useful projects around Visual Studio ALM here, if you are interested in contributing, let us know!

@OsirisOS

The Osiris logotype

So, the extension is now called Osiris AssociateRecentWorkItems and is available at https://visualstudiogallery.msdn.microsoft.com/3fa82205-e0f0-4874-a38b-023435fa2802

Hope that you will find it useful. I do plan to add support for Git, when I get around to it! Please poke me if you want it done sooner than later.. 🙂

Building GitHub repositories in TFS Build vNext

In the brave new world of Microsoft where a lot of the frameworks and languages that they build now are open sourced over at GitHub, it comes as no surprise that GitHub is nicely integrated into both
Visual Studio and TFS Build vNext. This makes it very easy to setup builds that gets the source code from your GitHub repo but uses TFS Build vNext to build it. It also allows you to setup CI builds, that is
builds that trigger automatically when someone does a commit in the corresponding Git repo.

Let’s see how this work:

First, you’ll need a GitHub repo of course.
Note: If you haven’t checked out the GitHub for VisualStudio extension yet, try it out. Makes it easy to clone your existing repos as well as creating new
ones, right inside Visual Studio.

Clone existing repos Create a new GitHub repo
Here, I create a FabrikamFiberTFS repo on GitHub where I’ll upload the code to
Now, to enable the TFS Build vNext integration, you need to create a Personal Access Token in GitHub. To do this, click the Settings link below your profile image in
GitHub, and then click on the Personal Access Token link:
Give the access token a name that you will remember(!), and then give it these permissions:

NOTE: In order to configure triggering CI builds, you must have admin permissions on the GitHub repo.
Save it, and the copy the access token that is displayed.
NOTE: Store this token somewhere safely, you will not be able to view it again. You probably want to setup a personal access token that works
for all your GitHub repos, if so you need to remember this access token.
Now, create a new build definition in your Visual Studio Online/TFS team project. Head over to the Repository tab, and select GitHub as your repository tab:
Paste your token in the Access Token field. This will populate the Repository drop down and let you select amongst your existing GitHub repositories:

You will also be able to select which branch that should be the default branch.
To enable continuous integration for your build definition, go to the Trigger tab and check the Continuous Integration checkbox. When saved, this build
definition will now use the repo_hook permission against your GitHub repository to respond to commit events.
Save you build definition, and commit a change to your GitHub repository. A new build should be queued almost immediately.
When the build completes, you will see the associated commit as usual in the build summary. However, this commit link now points to the GitHub commit page instead:

Clicking the link shows the commit in GitHub:
To round this up, we will add a Build Badge to our Welcome page to get an indication of the current status of the build. Go to the General tab, check
the Badge enabled checkbox and save the build definition. This will expose a link that shows you the public URL to a dynamically generated icon that
shows the status of the latest build for this particular build definition:
Go to the home page and then to the Welcome page tab. If you haven’t created a welcome page yet, do so. Then add the following markdown to the page:
# FabrikamFiberTFS Build Status
![](URL_FROM_BUILD_BADGE_LINK)

In my case, the link looks like this:

# FabrikamFiberTFS Build Status
![](https://jakob.visualstudio.com/DefaultCollection/_apis/public/build/definitions/488c3645-8921-4753-af50-4a9569fc2d27/116/badge)
Save it and you will see a nice little badge showing the status of the latest build: