Overview of Visual Studio 2015 ALM

  • Mathias Olausson
  • Jakob Ehn


Visual Studio has grown from being "just" a great IDE for developing software on the Windows platform into a whole suite of tools that covers the entire lifecycle of application development on multiple platforms. When the first version of Team Foundation Server shipped in 2005, the suite was referred to as Visual Studio Team System. Now, the suite is referred to as Visual Studio ALM.


Visual Studio Work Item Continuous Delivery Task Board Release Management 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Visual Studio has grown from being “just” a great IDE for developing software on the Windows platform into a whole suite of tools that covers the entire lifecycle of application development on multiple platforms. When the first version of Team Foundation Server shipped in 2005, the suite was referred to as Visual Studio Team System. Now, the suite is referred to as Visual Studio ALM.

As shown in Figure 2-1, Visual Studio ALM supports all of the phases in the software development lifecycle, from requirement management and project planning, source control management, test management, build automation and release management, and getting information and insights into your running application from the end users.
Figure 2-1.

Visual Studio 2015 ALM Overview

Even though you can (and many still do) use Team Foundation Server only for source control, the full power comes when you start using all of the tools in the suite. Since everything is integrated, not only is it easy to get started, but you also get full traceability across the project lifecycle on all artifacts.

In this chapter, we will take a brief look at the different parts of the Visual Studio ALM suite, what functionality they support, and how they are connected to each other. This will lay the foundation for the rest of the book, where you will implement Continuous Delivery for your sample application with the help of Visual Studio ALM.

Agile Project Management

The start of most projects is collecting and prioritizing requirements. Visual Studio ALM offers out-of-the-box support for the most common process methodologies such as Scrum, Agile, and Kanban. The basic tools for implementing Scrum, such as backlog and sprint backlogs, have been available since Visual Studio 2012, but these tools have been continuously improved. The 2015 release has seen a lot of investment in the Kanban board and the task boards.

Figure 2-2 shows an example of a team dashboard in Team Foundation Server. As you can see, a lot of different information about the project can be visualized on the start page to quickly give an insight into the project status.
Figure 2-2.

Team Foundation Server Web Access home page

Process Templates

Team Foundation Server ships with three different process templates that serve as a foundation for your software development process:
  • Scrum

  • Agile

  • CMMI

These templates are “blueprints” for your project, which means that you can start by choosing the one that matches your process best, and then customize it to meet your needs.

No matter which process template you choose, you can use the different tools when managing your projects. These tools are examined in the following sections.

Product Backlog

The product backlog is a prioritized list of requirements that you continuously refine with your stakeholders. Every team has its own backlog (if they want it), but it is also possible to aggregate these backlogs on a higher level.

Figure 2-3 shows the backlog view where you can easily create new backlog items and prioritize them by dragging each item up or down in the list.
Figure 2-3.

Working with the product backlog

Depending on your development process, you might want to track bugs on the backlog, or you might want to handle them as tasks to an existing requirement. You can configure Web Access to handle both cases.

Sprint Backlog and Task Boards

When following the Scrum methodology, a project is divided into a set of timeboxed sprints, each sprint being, for example, two weeks long. The product owner together with the team decides which backlog items have the highest priority; these items should be at the top of the product backlog and then assigned to the next sprint.

In the sprint, the development team works together to break down each requirement into smaller tasks that are detailed enough to estimate how many hours that particular task will take. In Figure 2-4, you can see the content of a sprint, where each requirement (in this case, one bug and one backlog item) has been broken down into a set of smaller tasks. To the right you can see the overall workload in this sprint for the team and for each team member.
Figure 2-4.

The sprint backlog showing requirements and their tasks

During the sprint, each member is responsible for updating the status of their tasks, and for grabbing new ones when they can. The status of all tasks can be viewed on the task board, as shown in Figure 2-5. Each card on the task board shows the title, who is currently assigned to the task, and the number of remaining hours.
Figure 2-5.

The task board shows requirements across the states

Updating the remaining hours of each task lays the foundation for the sprint burndown (shown in Figure 2-6), which is a graph that show how much work is left in the sprint and a trend line that indicates if the team is on track for the sprint or not.
Figure 2-6.

A sprint burndown graph

Kanban Board

The product backlog can also be viewed as a board where each requirement or bug is tracked over a set of states. In this mode, you don’t focus on sprints and when each requirement is planned to be released. Instead the focus is to continuously work from the top of the backlog and to make sure that the most prioritized work items get implemented, tested, and delivered as quickly as possible.

This process methodology is often referred to as Kanban, and it has its roots in the world of lean manufacturing. Team Foundation Server supports this process by using the board view of the product backlog, as shown in Figure 2-7.
Figure 2-7.

Kanban board showing the flow of requirements

In this view, each requirement is displayed as a card that shows who is assigned what job, the currently estimated effort, and other information such as the work item id and the tags. Each card can then progress through the different stages by dragging them across the columns horizontally. The available columns in the board can easily be customized for each team to fit their process.

An important focus of a Kanban process is to make sure that there are no blocking points in the process; there should be a continuous flow of value to the stakeholders and end users. To facilitate this, every column in the Kanban board has a dedicated Work In Progress (WIP) limit that indicates the maximum number of items that should be assigned to that particular column. Also, a Cumulative Flow Diagram (shown in Figure 2-8) is available, which clearly shows the flow of value over time and can pinpoint if there are, or have been, steps in the process with low throughput.
Figure 2-8.

Cumulative Flow Diagram

Source Control Management

One thing every TFS team uses is source control. Since the first version, TFS has shipped with a first-class centralized version control system that can handle any size project, including Microsoft itself. However, in the last five years the trend within software development has been strongly in favor of distributed version control, which is a paradigm shift compared to centralized VCS such as TFS, CVS, and Subversion.

It was quite a surprise when Brian Harry, program manager of Team Foundation Server at Microsoft, announced back in 2012 that Microsoft was implementing first-class support for Git within TFS and Visual Studio. What’s important to understand is that this is not a Microsoft-specific variation of Git; it is a full fidelity implementation of the Git protocol. This means that you can use any Git client out there, on any platform, and use TFS as your source control provider. And you can use Visual Studio as a Git client against any hosted Git server, such as GitHub or BitBucket.

What Microsoft does bring to the table is support for Enterprise Git, which means things such as repository and branch security, commit policies, and integration with work items and build automation.

We will talk more about the differences between centralized and distributed version control in  Chapter 5. When it comes to the process of Continuous Delivery, it doesn’t really matter if you choose a distributed or a centralized version control system. What is important is that everything that is part of the automated build and deployment pipeline is stored in a versioned repository so that you at any given time can reproduce a given version of the application by simply building the same commit or changeset.

Build Automation

A crucial part of Continuous Delivery is Continuous Integration, which is the process of taking every changeset from the developers and verifying that it compiles, that all the unit tests still work, that the application can be deployed onto an integration environment, and that the smoke tests succeed.

The cornerstone of Continuous Integration is build automation. Having builds that run on every new changeset quickly becomes the heartbeat of the project, and it should beat successfully several times every day. If it fails, the team must make it a top priority to fix the build as soon as possible.

With Visual Studio 2015, Microsoft ships a brand new build system, currently referred to as Build vNext, which replaces the Windows Workflow XAML-based build engine that shipped with TFS 2010, 2012, and 2013. The reasons for investing in a whole new version of TFS Build are mainly the following:
  • Easy customization: The biggest pain point with the existing XAML build system was build customization. Learning Windows Workflow just to add a few simple build steps required learning a new language and toolset plus a lot of project infrastructure to get the designer experience working properly. In most cases, what developers or build managers want to do is to run scripts at a certain point in the build process. The new build system focuses on this.

  • Cross-platform support: Supporting only Windows is no longer an option for Microsoft. The new build system comes with a cross-platform agent that runs on both Linux and Mac OSX.

  • Better use of build resources: The new build system has no concept of a controller that is tied to a project collection. Instead, you define one or more agent pools, and then you install build agents that belong to a pool. There can be multiple build agents on the same machine, and they can belong to different pools as well.

  • Don’t mess with my build output: Another concern with the XAML-based build system was the way that it by default changed the way the output of the build ended up. One of the key principles of the new build system is that Dev build = CI Build, which means that there should be no difference in building your application on your local compared to the build server.

Figure 2-9 shows the web UI for creating build definitions. A build definition is simply a set of tasks that are executed in a particular order.
Figure 2-9.

Authoring build definitions in TFS 2015


All the tasks that ship with TFS and the build agent itself are open sourced at GitHub, at and .

The new build system runs side by side with the old build system, now referred to as “XAML builds.” You can even have standard build agents and XAML build agents running on the same machine. TFS will continue to support XAML builds for the foreseeable future, but don’t expect any new functionality here. The message is clear from Microsoft: for all new investments that you do in TFS build automation, you should use the vNext system. If you have done a lot of customization with XAML builds, keep them around but start planning for migration.


Even though this build system is brand new, it is the recommended way to work with build automation when using TFS going forward. For this reason, we will use this system for implementing build automation in this book. Note, however, that everything we show can also be done using XAML builds.

Test Management

Maintaining high quality throughout the lifecycle of the application is of course of uttermost importance. There are several ways of measuring and enforcing software quality, but no doubt a successful testing strategy and implementation is one of the most important.

As you will see throughout this book, Visual Studio ALM supports all types of tests common during the lifecycle of a project. This includes unit tests, automated acceptance tests, manual tests, and exploratory testing. Since Continuous Delivery is all about automating all parts of delivering software, we will focus on the automated tests. The testing tools in Visual Studio ALM actually allow you to record a manual test and later generate code for it that can be used as an automatic regression test to verify the same behavior.

Unit tests are developed and maintained within Visual Studio. Since the 2012 release, Visual Studio supports multiple testing frameworks such as NUnit, XUnit, and MSTest.

When it comes to manual tests, these are authored either using the web access or using a separate tool called Microsoft Test Manager. Under the hood, manual tests are defined using a work item type called Test Case, and can be grouped into test suites and test plans to match the release cycle of your project. Figure 2-10 shows a test plan with a few test suites and test cases in the web UI.
Figure 2-10.

Managing test plans, test suites, and test cases

Running the tests can also be done using either the web access or the Microsoft Test Manager (MTM) client. The biggest difference between them is that MTM can collect a lot of diagnostic information during the test run, which is very valuable if a bug is found during the test. When the tester posts a bug into TFS, the diagnostic information is automatically attached to the bug, making it much easier for the developer to understand and reproduce the bug. Figure 2-11 shows the MTM test runner in action. The MTM test runner guides the tester through the steps of a test case.
Figure 2-11.

Running a test case in MTM

Release Management

For quite some time, there was a gap in the Visual Studio ALM suite around deployment and release management. The toolset allowed you to do everything up until when you produced a set of versioned binaries and packages ready for deployment. From there you had to either roll your own or look for other vendors in the market.

That changed in 2013 when Microsoft acquired InRelease from InCycle Software Inc., which was then renamed Visual Studio Release Management.

Visual Studio Release Management provides the tools for deploying a certain version of the application components to various target servers in different environments, in a controlled and fully audited fashion, as shown in Figure 2-12. Configuration management is built into the product, letting the team define all environment-specific variables, such as database connection strings and file paths, in one secure place.
Figure 2-12.

Visual Studio Release Management architecture

It also implements an approval workflow on top of the deployment pipeline that lets different roles in the organization verify and approve a deployment before it moves on to the next environment.

Since the acquisition, Microsoft has added several new features. The most important one is revamping the deployment pipeline to rely on PowerShell, and more specifically PowerShell DSC (Desired State Configuration), as the deployment mechanism. This also means that it is no longer necessary to install a deployment agent on the target machines.

Visual Studio Release Management also integrates directly with Microsoft Azure, exposing all of your existing environments and servers, making it very easy to set up automatic deployment across the different environments that are available in your Azure subscription.

In Team Foundation Server 2015 Update 1, Microsoft ships a major new version of Visual Studio Release Management that replaces the existing version. The new version is entirely web-based and uses the same task platform with the new build automation system. In this book, you will use this new version to implement a Continuous Delivery pipeline for your sample application.

We will explore Visual Studio Release Management thoroughly through the rest of this book, since release management is a foundational part of Continuous Delivery.

Cross-Platform Support

In the last year or so, the world has realized that Microsoft is no longer the company that it used to be. They have broken down several barriers, the most noteworthy of which was the decision to open source the entire .NET Framework and related technologies on GitHub.

Microsoft has also realized that they can’t force their customers to be all-in on Windows; they need to embrace more and more platforms since this is where the software industry is moving. There are many examples of this, such as the possibility to create virtual machines running Linux in Azure, and the collaboration with Docker to bring support for the popular container technology to the Windows platform.

Within the developer tools platform, there has been lots of investment in supporting cross-platform mobile development, both using the Xamarin platform built on top of Mono.NET and the Apache Cordova framework (previously known as PhoneGap), which is based on JavaScript and HTML.

At the //Build 2015 conference, Microsoft even revealed a completely new IDE called Visual Studio Code that runs on Windows, Mac, and Linux, and supports the development of modern web applications using languages such as C#, JavaScript, TypeScript, and HTML. It has IntelliSense and support for debugging. At the time of writing, it is still in preview.

Also, the new build system mentioned above has agents for running both on Linux, Mac, and Windows.

Integration and Extensibility

Extensibility has always been important for Microsoft, and Visual Studio is built as an extension itself where everything that you use is an extension to the default Visual Studio Shell.

Team Foundation Server has had a great client object model from the start, but there have been some important pieces missing when it comes to extensibility. These pieces have been added in TFS 2015, and the extensibility story is now very strong.


The client object model that has shipped since the first version of TFS is a set of .NET class libraries. Although the functionality was very powerful, the lack of support for other platforms and the fact that you must install Visual Studio Team Explorer to get the client object model on a target server caused a lot of problems for partners and organizations that wanted to extend TFS.

Enter the REST API. All new functionality that Microsoft currently ships comes with a REST API that can be accessed from anywhere and that uses standard web authentication protocols such as OAuth. This opens up a lot of new integration opportunities, for example in the area of mobile applications that can’t use the current client object model.

Here is an example of a REST API endpoint that returns all build definitions in a team project:


This is a HTTP GET request against a server called TFS that returns all build definitions defined in the QBox team project. The response looks like this:

{"value": [{"batchSize": 1,"uri": "vstfs:///Build/Definition/3","queue": {"queueType": "buildController","id": 3,"name": "Default Controller - TFS","url": " http://TFS:8080/tfs/DefaultCollection/_apis/build/Queues/3 "},"triggerType": "none","defaultDropLocation": "\\\\localhost\\drop\\QBox","buildArgs": "","dateCreated": "2014-12-28T19:38:02.753Z","supportedReasons": 63,"lastBuild": {"id": 119,"url": " http://TFS:8080/tfs/DefaultCollection/e58abadf-cfef-49c5-82d8-4725b010ca9d/_apis/build/Builds/119 "},"definitionType": "xaml","id": 3,"name": "QBox.CI","url": " http://TFS:8080/tfs/DefaultCollection/e58abadf-cfef-49c5-82d8-4725b010ca9d/_apis/build/Definitions/3 "}],"count": 1}


You can explore the full documentation for the REST API at .

Service Hooks

Even though TFS supports all aspects of the application lifecycle, there are plenty of other vendors out there who deliver great solutions in the different areas of application lifecycle management. Instead of trying to force customers to stop using these solutions, TFS embraces them by allowing the end users to integrate with them instead.

This is done using service hooks, which enable you to perform tasks on other services when something happens in Team Foundation Server. A typical example of such an event is when someone creates a new work item or a running build is completed. This event will then execute a web request to an external system, for example to create or update a card on a Trello board or trigger a Jenkins build.

Examples of service hooks that ship with TFS 2015 include
  • Trello

  • Slack

  • Campfire

  • HipChat

  • Azure

  • Jenkins

There is also a general Web Hooks service that lets you integrate with any service that can be triggered by an HTTP POST request.


For a current reference list of available service hook consumers, see

Extensions (Apps)

As mentioned before, Visual Studio itself has been extensible from the very beginning. However, the most visible part of Team Foundation Server, the web access, has not been extensible at all. This has definitely changed in the 2015 release, with the introduction of extensions. Extensions are basically context-aware web pages that can be included at different places in the portal. These places are called extension points and can, for example, be a new tab at the top level or a new context menu item in the product backlog.

Figure 2-13 shows the Calendar extension that was published as a sample from Microsoft. This extension adds a new tab in the Home hub that shows a calendar for the team.
Figure 2-13.

The Calendar web access extension from Microsoft


Extending web access is available on Visual Studio Online, and will be shipped with TFS 2015 Update 1.

Looking ahead, Microsoft will provide a marketplace for web access extensions that will let end users easily locate and install third-party extensions. This is not available at the moment, but it is in the roadmap for extensibility.

Application Insights

The last piece of the ALM puzzle is knowing how your application performs in the wild and how your users are using it. Application Insight is a cloud-based service hosted in Microsoft Azure that collects data from your applications and lets you visualize and search information within the Azure portal. Information is collected by adding an SDK to your applications that continuously sends telemetry to the portal. There are SDKs for most platforms, such as web applications, Windows store applications, Xamarin mobile applications, and Java applications. This telemetry contains detailed exception diagnostics as well as usage information, such as which pages users visit most frequently.

In addition to collecting telemetry from the application, Application Insights lets you monitor your applications from the outside by setting up simple ping messages or more complex web tests that can check if your application is accessible and if it works as expected (see Figure 2-14).
Figure 2-14.

Application Insights Overview timeline

In  Chapter 12, you will instrument your different application components with Application Insights and learn how this information can be accessed in the Azure portal.

Visual Studio Online

As part of its cloud offering, Microsoft also supports Visual Studio ALM as a service. Named Visual Studio Online, it is an offering that contains all the parts mentioned above, but hosted in Microsoft Azure (see Figure 2-15). In addition, it offers cloud-specific services such as Cloud Load Testing, which lets you use Azure to scale up your load testing.
Figure 2-15.

Visual Studio Online

Almost everything you can do on premise using Team Foundation Server you can do on Visual Studio Online. The only major components that are missing in Visual Studio Online compared to TFS are the SharePoint team portal and the SQL Reporting Services TFS reports.


Another major limitation is that it is not possible to customize the process templates in Visual Studio Online; you can only use one of the three default templates as-is. Microsoft is currently working on this and the feature should be available in some form by the time this book is published.

You can read more about the roadmap for process customization in Visual Studio Online at .

There are a few other minor differences, and we will point them out throughout the book. If not stated otherwise, everything that we show in this book can be done either using TFS on premise or using Visual Studio Online.


In this chapter we walked you through all of the major parts of the Visual Studio ALM suite. We have only scratched the surface of each part; the rest of the book will dive deeply into each area when you implement Continuous Delivery for your sample application using the tools and features mentioned in this chapter.

In the next chapter, you will take a brief look at the reference application QBox. You will use QBox as a baseline application for implementing Continuous Delivery using the Visual Studio 2015 ALM Suite.

Copyright information

© Mathias Olausson and Jakob Ehn 2015

Authors and Affiliations

  • Mathias Olausson
    • 1
  • Jakob Ehn
    • 1
  1. 1.LerumSweden

Personalised recommendations