The evolution of Microsoft’s solution for Application Lifecycle Management: Team Foundation Server – Part IV

November 11, 2013

Part I: Introduction

Part II: Diving into the basics of ALM and how did Microsoft start with an ALM solution?

Part III: Heterogeneous Software Development

Part IV: A fully integrated testing experience with TFS 2010

The third release of Microsoft’s ALM Solution (Visual Studio 2010) no longer used the Team System moniker and brought all the available SKUs back under the good old Visual Studio brand. The 2010 release was definitely the most significant release with many new functionality and improvements since the launch of the product with Team System 2005. Microsoft put a lot of effort into building a full testing experience into Team Foundation Server with a test management suite for managing test planning and for running manual/automated UI tests, including the ability to analyze test impact based on code changes. The Lab Management solution on top of TFS was quite revolutionary and can now be seen as the first indications of the growing importance of automated deployment and testing.


As a result, Gartner included Microsoft as Visionary for the first time in their Magic Quadrant for Integrated Software Quality Suites (published report of January 2011).

Microsoft Test Manager (MTM) was the new kid on the block and could be purchased separately with the Test Professional Suite (with MSDN Subscription). The Ultimate edition of Visual Studio also contained Microsoft Test Manager. Many existing testing tools on the market focused particularly on helping specialists testers (strong programming/scripting skills) with white box testing and API testing, but the majority of testing activities in the industry was still done manually (black box testing) while not a lot of testing tools provided extra support for this manual work. Consider MTM as an integrated test environment (ITE) for testers, compared to an integrated development environment (IDE) for developers.

The new SKU wanted to provide a bridge between the testing team and the development team. It’s the interface that a tester will use to create test cases, organize test plans, track test results, and file bugs when defects are found. Test Manager is integrated with Team Foundation Server, and is designed to improve the productivity of testers.


An interesting feature was for example the ability to play back action recordings to fast forward to a particular test step in a manual test to verify if a bug was fixed. It was also possible to create automated UI tests in Visual Studio (known as Coded UI Tests) using new automation libraries. You could generate C#/VB.NET code in Visual Studio from an existing action recording and add validation code to verify that the application under test was performing correctly.

The most compelling story was to file actionable bugs as a tester to avoid the typical ping-pong game between developers and testers. Familiar with the famous “it works on my machine” reply from the developer who marked the bug as non-reproducible? During a manual/automated test run with the built-in Test Runner, a lot of Diagnostic Data Adapters (DDA) could be enabled (test settings) to automatically collect and attach all data to a new Bug report: video recording, system information, IntelliTrace, Test Impact Analysis, screenshots, … It became plain easy for a tester to gather all important information and send it to the development team for further validation. Next to this, test managers could follow up which builds had bug fixes and/or new features added. They were also presented with recommendations about which tests needed to be rerun, based on the effect of code changes that were made to the codebase (test impact analysis on managed code). Instead of rerunning all test cases over and over again, testers could stay up-to-date with a new iteration by designing new test cases.


The icing on the cake for me was Visual Studio Lab Management 2010, an add-on for TFS 2010 which extended the Build Automation feature. It allowed builds to easily deploy their output to virtual environments which could exist of multiple virtual machines. Relying on the snapshotting features of the virtualization technology (Hyper-V), complete environments could be rolled back to a known clean snapshot/checkpoint to always enforce a clean deployment for each new manual/scheduled build. Automated Tests could be integrated in the Build-Deploy cycle of the Lab Build to validate each new deployment. The ultimate goal was to detect bugs as soon as possible in every incremental update of your application in Development and once a defect was found, all collected data through the collectors could be easily stored in an actionable bug report. No more no repro!

Team Foundation Server 2010 was designed to be easily customizable and extensible. TFS ensures that developers using any development platform can participate. This was also identified by an independent ALM study of Gartner, published in a report in June 2012. Microsoft has been identified as a leader in this area with the TFS 2010 offering. This is a clear indication that Microsoft has great tools for Application Lifecycle Management. Many larger companies also needed to think about compliance (Sarbanes-Oxley Act). This is often a very important and crucial requirement when choosing an enterprise ALM tool. Team Foundation Server 2010 provided three main pieces of functionality as it relates to SOx – Work Item Tracking, Version Control and Automated Build. These three features working together provided the capability to eliminate many of the risks associated with SOx 404 compliance. At the heart of SOx is the ability to know who made what change when, what requirement was the change made for and who authorized the change to be made. Was the requirement tested to make sure that it works correctly and who authorized the release of that requirement to production? Or, to state it another way, is the requirement traceable? Many technical solutions require multiple tools to provide this kind of traceability and most of the time they break the traceability chain at some point because they are not integrated at all required points. With Team Foundation Server 2010, full traceability was baked in. Team Foundation Server provided a comprehensive and flexible set of capabilities through traceability, test case management and automated builds. The rich extensibility of both the built-in features and a third-party ecosystem produce tools your company need in order to meet the requirements of SOx. A full article on Sox and TFS 2010 is available at

In the next part (Part V) I will continue with the release of TFS 2012 and the spring of the cloud story: running TFS on Windows Azure.

Part V: TFS 2012 and Continuous Value Delivery

Part VI: TFS 2013 and Visual Studio Online

Part VII: Conclusion


The evolution of Microsoft’s solution for Application Lifecycle Management: Team Foundation Server – Part III

November 8, 2013

Part I: Introduction

Part II: Diving into the basics of ALM and how did Microsoft start with an ALM solution?

Part III: Heterogeneous Software Development

What about cross-platform development in the early versions of Microsoft Visual Studio Team System? Microsoft did not have a solution for this. Teamprise – founded in 2006 as a division of SourceGear – developed a suite of client applications for accessing Microsoft Visual Studio Team Foundation Server from outside the Visual Studio client environment. Teamprise enabled developers to use the source control and work item tracking features of Team Foundation Server from other platforms (operating systems that support a Java Runtime Environment), including Linux, Solaris and Mac OS, and from within the Eclipse IDE through a plug-in.


This plug-in was also compatible with IBM’s Websphere Studio and Rational Application Developer IDE. There was also a stand-alone Teamprise client application (written in Java) which featured an Explorer-style user interface for developers not working within an IDE. The product was written by accessing the Team Foundation Server SOAP web services. A bit later in 2007 the company also started working on a Java SDK for use with Team Foundation Server. Big enterprises and third-party software vendors were interested in using libraries developed by Teamprise in order to link existing Java products with Team Foundation Server data. This addition was opening up a large set of core libraries to expose functionality to Java developers in the form of an API they can use to build their own TFS-enabled applications.

TFS 2008

Back in November 2007, Microsoft released a new version of the Team System product: Visual Studio Team System 2008. This release can be seen as the first update to the Team System brand. Visual Studio 2008 Team Foundation Server delivered improvements in several areas, such as enhanced features in Team Build and version control, better performance, scalability and more flexible configuration. But it was only in November 2009 that Microsoft acquired Teamprise to provide cross-platform support for Visual Studio. It was announced that functionality from the Teamprise Client suite would be integrated into the Visual Studio product line, beginning with the next version of Visual Studio (Visual Studio 2010). TFS in combination with the Teamprise Client Suite technologies would enable development teams to use a single tool to overcome core development challenges, regardless of the core platform in use. This decision by Microsoft was a commitment to provide ALM tooling support across the entire enterprise, a desire to avoid the artificial technological boundaries inside big companies. Heterogeneous development was at that time officially a new focus for the TFS/ALM product team inside Microsoft and the old TeamPrise (Java) developers joined the team. A few months later in April of 2012, Microsoft came up with a (temporary) name for the product: Microsoft Team Explorer 2010 codename “Eaglestone”, or TEE in short. The Program Manager for the new addition to the Visual Studio product suite was Martin Woodward, a senior software engineer from the former TeamPrise employees.

TFS 2010

At the global Visual Studio 2010 launch event in Las Vegas (April 2010) Visual Studio Team Explorer Everywhere (TEE) was announced. The Teamprise features were now completely integrated and part of the Microsoft solution set for development teams.


Announcement details:

Previously sold as a separate product, Visual Studio Team Explorer Everywhere 2010 works with your favorite Eclipse-based IDE, in the operating system of your choice, and helps you collaborate across your .NET and Java development teams using Team Foundation Server 2010. It’s an easy-to-install standalone plug-in that’s now a free download.


Java developers of course also need to run builds and are adopting continuous building/integration practices. So, why not provide this via TFS Builds?

The Team Foundation Build Extensions (to be installed on the Team Foundation Build Agent) offered the ability to execute Ant or Maven 2 builds from Team Foundation Server and publish the results of the build along with any associated JUnit test results back to Team Foundation Server. This release was compatible with Team Foundation Server 2005, Team Foundation Server 2008 and Team Foundation Server 2010.

Team Explorer Everywhere and the Build Extensions got also updated in the newer versions of TFS to improve the Team Explorer experience in the non Visual Studio world.

I would also like to add a link here to a previous blogpost I made in March 2012, where I write more in detail about the benefits Team Foundation Server may offer in a heterogeneous software development environment: TFS as a true cross-technology ALM platform.

Next Part (Part IV) will tackle the integration of new Testing tools into the ALM solution with the release of Team Foundation Server 2010.

Part IV: A fully integrated testing experience with TFS 2010

Part V: TFS 2012 and Continuous Value Delivery

Part VI: TFS 2013 and Visual Studio Online

Part VII: Conclusion


The evolution of Microsoft’s solution for Application Lifecycle Management: Team Foundation Server – Part II

November 8, 2013

Part I: Introduction

Part II: Diving into the basics of ALM and how did Microsoft start with an ALM solution?

According to Wikipedia:

Application lifecycle management (ALM) is the product lifecycle management (governance, development, and maintenance) of application software. It encompasses requirements management, software architecture, computer programming, software testing, software maintenance, change management, project management, and release management.

For each specific technology, there exist one or more dedicated ALM tool(s) in the market. Only a few tools offer true support for cross-technology Application Lifecycle Management. Serena offers a number of related tools for requirements management, version control and release management. Serena Dimensions CM integrates for example with many popular application development tools straight out of the box like Visual Studio (.NET) and Eclipse (Java). Another example is Rational Team Concert (RTC) from IBM which is positioned as a lean collaborative lifecycle management solution. IBM also offers a rich RTC client plugin for Eclipse and Visual Studio. Atlassian is an Australian software company which focuses on issue tracking, collaboration and other related software development products to work faster and smarter, together. Their tools are very popular in the Java community, but they also offer a Visual Studio Connector to interact with JIRA issues and Bamboo builds right from Visual Studio. The Atlassian tools in combination with a powerful version control system like Git or Mercurial can also be seen as a competitor in the cross technology ALM space.

But for now I want to highlight Microsoft’s Application Lifecycle Management solution. Microsoft Visual Studio 2013 will actually be officially released on November 13, 2013 at the Visual Studio 2013 Virtual Launch Event. The RTM version has been made available for a few weeks already and can be downloaded at

Some history about Team System

Let’s get back in time when it all started. Microsoft released in November 2004 (9 years ago) their first version of an integrated application lifecycle management solution (codename Burton): Microsoft Visual Studio Team System 2005. Before, Visual Studio was only a dedicated tool for developers/coders. This shifted completely with the release of Team System where multiple stakeholders were involved in the software development process.


Microsoft studied the way how software teams developed software and decided to build a new product that would substantially increase the likelihood of project success, predictability and software quality. Team System actually transformed the Visual Studio IDE into a powerful collaboration tool for the entire software development team. Visual Studio 2005 Team System was designed to achieve four primary goals:

  • Be productive by reducing the complexity of delivering modern service-oriented solutions
  • Be integrated with all tools, and facilitate better team collaboration
  • Be capable by being robust, secure, and scalable, and by having the ability to work remotely
  • Be extensible by allowing processes to be customized

The complete solution consisted of a series of different editions, targeted to the various stakeholders:

  • Visual Studio 2005 Team Edition for Software Architects
  • Visual Studio 2005 Team Edition for Software Developers
  • Visual Studio 2005 Team Edition for Tester
  • Visual Studio 2005 Team Foundation Server

A common misconception was that TFS replaced Visual SourceSafe as just a new version control system. This is of course incorrect because version control is only a small part of the TFS feature set. Team Foundation Version Control (TFVC) was written from scratch (no link with SourceSafe) and uses a SQL Server database as a means of scaling to large environments and infrastructures.


Team Foundation Server is the central and key component in the ALM solution which offered extensible team collaboration. Team System was clearly designed as a lifecycle platform that enabled third-parties, customers, and solution providers to extend the base functionality with new features and customize the tool for the unique aspects of certain businesses. The Microsoft Solution Framework (MSF) – a set of software development processes, principles, and proven practices – was merged into the product via two Team Project process templates: MSF for Agile Software Development and MSF for CMMI Process Improvement.

At this time, the target audience for Team System were (large) enterprise development teams with a focus to improve the joint outcome of software development on the Microsoft platform (.NET). No sign yet of cross-platform development tools or support for multiple (non-Microsoft) development languages. Visual Studio 2005 Team System can be seen as v1 of the ALM offering from Microsoft. Later in 2006 another client Team System edition was added to the offering: Visual Studio 2005 Team System for Database Professionals. The DB Pro or Data Dude edition worked in conjunction with version control to manage database changes next to application code changes.

In Part III I will cover how Microsoft is extending their ALM offering in the next versions to typical non-Microsoft customers: a look at heterogeneous software development.

Part III: Heterogeneous Software Development

Part IV: A fully integrated testing experience with TFS 2010

Part V: TFS 2012 and Continuous Value Delivery

Part VI: TFS 2013 and Visual Studio Online

Part VII: Conclusion


The evolution of Microsoft’s solution for Application Lifecycle Management: Team Foundation Server – Part I

November 7, 2013

In the light of the upcoming official release of Visual Studio 2013 (November 13, 2013), I was planning to write a small blog post to have a quick look at how the product of today evolved over the years. My intention drove me eventually to come up with an elaborated article on this topic which I have splitted in different parts. Thanks to my fellow Visual Studio ALM MVP René van Osnabrugge for reviewing my text and for giving some tips to link it all together!

Part I is setting the scene and covers the introduction …

Software development is so much more than only writing technology specific code (.NET, Java, PHP, Mainframe, …). Applications are also becoming more complex due to numerous distributed services and the boundaries of an application are becoming less clear. Nearly all large enterprises struggle with communication, collaboration and cultural gaps between business users who drive the competitive need for software development, software teams who create the software, and the IT Operations team who manages application deployment and maintenance. IT departments are still often siloed internally with poor hand-offs between development teams and inconsistent approaches to core project life cycle phases and roles (architect, project manager, developer, database administrator, tester, configuration/release manager, …). This negatively affects design, quality, code management and the final deployment of software applications into a production environment.

On top of these issues, it’s quite interesting to see how different technology stacks are coming together in the bigger traditional enterprises. Product features or requirements are not only managed anymore for a specific technology stack but go way beyond specific implementation choices. A complete release/solution can easily consist of a customer facing website written in .NET which connects to Java Web Services for business transactions. The data used for processing could easily come from multiple other applications/sources (don’t forget the existence and importance of many Mainframe applications!). And I didn’t mention yet the different options that pop up if you want to offer a mobile solution on various devices and platforms. At a time of increasing costs, competitive pressure and greater complexity for business requirements, organizations require intuitive, accessible and integrated products. Most organizations have highly constrained resources and add outsourcing to the mix, which further drives the need for better prioritization and metrics for measuring IT success. In addition, regulatory compliance legislation is pushing organizations towards greater rigor with regards to application lifecycle management. On the other side of the spectrum we can identify the need for continuous delivery. Business expects IT to deliver new incremental features as fast as possible. Time-to-market has never been as important as now and can create an important competitive advantage. But let’s face it, many organizations are still far away from the continuous delivery dream. It’s not something which can be easily adopted over the week-end.

In this article I will write about the interesting evolution of Application Lifecycle Management (ALM) and the increased importance of (heterogeneous) software development processes. What I described above about continuous delivery should obviously be the ultimate goal to achieve, but it’s important to set out a realistic roadmap. Don’t run before you can walk and take your time to introduce important changes in your organization. A well-defined ALM strategy is essential to achieve the goals of the IT organization while closely aligning the direction of the business. The key for success is finding a balance between processes, tools and people.

In my next blog post, I will cover Part II to dive into the basics of Application Lifecycle Management and how Microsoft released the first version of Team System.

Part II: Diving into the basics of ALM and how did Microsoft start with an ALM solution?

Part III: Heterogeneous Software Development

Part IV: A fully integrated testing experience with TFS 2010

Part V: TFS 2012 and Continuous Value Delivery

Part VI: TFS 2013 and Visual Studio Online


Part VII: Conclusion

Confusion about agile forecasting in TFS

August 5, 2013

Microsoft introduced with TFS 2012 a nicely integrated set of Agile Project Management features (Planning and Tracking) which became part of the redesigned Team Web Access portal.

One of the interesting features is the ability to forecast which product backlog items will (potentially) be delivered in future sprints, based on the velocity of the development team.


This view is your ideal partner when you want to discuss the release schedule of individual product backlog items with the business. It will become clear that moving things up/down will have impact on the delivery date (Sprint). It will visually show the business that each Sprint has boundaries and it’s not possible to quickly add more stuff to the upcoming Sprint. Other PBIs will be dropped from the Sprint. Sure, the business is entitled to move things up, but as a result other things will automatically go down.

Unfortunately, the view is a bit confusing and I already had a number of discussions during my ALM training sessions on this topic. The image above shows horizontal lines as the boundary for future Sprints. Forecasting in the example is enabled and based on a velocity of 10 Story Points. The key here is to understand whether the Sprint number is set above the top line of the Sprint “box” or if the Sprint number is set above the bottom line of the Sprint “box”. Almost everyone believes at first sight that Sprint 2 will contain PBI 4, 5, 6 and 7. But that’s incorrect because the Sprint number is set above the bottom line of the Sprint “box”. So, PBI items 1, 2 and 3 are forecasted to be delivered in Sprint 2 (total of 9 Story Points) and PBI items 4, 5, 6 and 7 are forecasted to be delivered in Sprint 3 (total of 10 Story Points).


The forecasting feature is currently incorrectly explained in the ALM hands-on exercise about the Product Backlog and Sprints.

A nice way to avoid the confusion could be for example to use some alternate coloring to show exactly what belongs to a specific Sprint or to add the Sprint number to each line in the Forecast column.

Hope this helps to get it right!

Update TFS proxy account (small bug)

July 8, 2013

A few weeks ago I ran into a small bug when updating the TFS proxy account (domain account) via the TFS Administrator Console on the TFS 2012 proxy server.



So, the UI does not provide a way to immediately switch to another domain account. The bug has been reported to the TFS product team and a fix will be provided in the (near) future.

Here’s a possible workaround (until it gets fixed in the product):

  • Unconfigure proxy in TFS Administration Console
    • Select Root node in TFS Administration Console
    • Click on the “Remove Feature” link on the right
    • Choose “Team Foundation Server Proxy” and click “Remove”
  • Reconfigure proxy
    • Select “Proxy Server” node and “Configure installed features”
    • Run “Configure TFS Proxy” wizard

Community Day Belgium 2013: session about Team Foundation Service

June 21, 2013

This year’s Community Day event was again great with no less than 5 parallel technical tracks, a good mix of Dev & IT Pro oriented sessions.

I had the pleasure this year to present together with Kevin DeRudder. Our goal was to show how easy it is to use Team Foundation Service (TFS in the cloud) for storing your source code and for making use of the cloud ALM features like Agile Project Management, Build Automation and Test Case Management.

We demoed how to build a Windows 8 App and how you can remotely test the application on a Surface RT tablet with Microsoft Test Manager 2012. Along the way we also touched a number of new features in VS/TFS 2012: My Work, Suspend & Resume, Code Review, Code Maps.

Slides of our session can be downloaded here.


Get every new post delivered to your Inbox.