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

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

Part V: About TFS 2012, the Cloud, Git and the new shipping cadence

The next major release of Team Foundation Server (TFS 2012) was released on September 12, 2012. Some of the key new features in this release were full integration of Agile Project Management through a new improved Web Access UI, involvement of feedback from other stakeholders in the software development process by using PowerPoint StoryBoarding and the Feedback Client, increasing the productivity of developers by introducing a new Team Explorer UI and by providing important version control enhancements like the availability of Local Workspaces.

Continuous Value Delivery

The main theme of this release was Continuous Value Delivery. TFS 2012 delivered workflows and tools that are able to shorten delivery cycles, include customers and operations (non-development stakeholders) in software construction, and it looks for opportunities to reduce waste in the software development process. As a result, your organization should be able to reduce risks, solve problems faster, and continuously deliver value that exceeds customers’ expectations.

Primary goals of ALM with Visual Studio 2012:

• Prioritize collaboration among everyone involved in developing an application, incorporating customers as equal members of the development team.
• Deliver timely and actionable feedback to reduce wasted effort and its associated costs.
• Provide natural and appropriate tools for the tasks involved in designing, developing,  testing, delivering, and maintaining quality software.
• Support best practices for application development, while remaining independent of any specific methodology.

Reflecting on the impact this release had for many of my customers, it must have been the best release of Team Foundation Server. The majority of the new big features were easy to demonstrate and it didn’t take long to convince decision makers of the business value to upgrade old TFS environments to TFS 2012 or to introduce it to new customers who were struggling with implementing ALM in general. There were so many known pain points in software development tracks which could benefit heavily from built-in solutions in the TFS 2012 release. Think about for instance the possibility to shorten the feedback loop between business and the development team, but it also included important development productivity features like explicit code reviews in the daily workflow of developers and the inclusion of a new improved diff/merge experience. After feeling a bit lost in the redesigned Team Explorer UI in the beginning, it became clear that it focused more on a task-oriented approach, freeing the development team from many of the distractions that can occur when working on a complex project and enabling the team to work more quickly and more efficient (for example: Suspend-And-Resume functionality to stay in the zone). Testing became a true first-class citizen in the development process with a unified Test Explorer in Visual Studio and a unique way to perform automated and exploratory testing from Microsoft Test Manager.

DevOps

Team Foundation Server 2012 provided also a server monitoring solution for teams that use or want to adopt System Center Operations Manager (SCOM). A monitoring agent can be installed/configured for ASP.NET applications running on a web server. This agent collects rich data about exceptions, performance issues, and other errors. Using the TFS Connector for SCOM, Operations staff can file these exceptions as operational issues (work items) in TFS and assign them to the development team to investigate in order to improve and fix production web applications. Visual Studio and the TFS connector, in conjunction with SCOM, provide a real-time improvement feedback loop for server-based applications deployed in production environments, leading to continuous improvements, an increased mean time to repair (MTTR) cycle and better quality in the end of the application in production.

The Cloud Story

More importantly, Microsoft has also been working very hard on an ALM “cloud” offering in this timeframe: Team Foundation Service or Team Foundation Server in the cloud. A preview of Team Foundation Service was announced for the first time at the BUILD Conference in 2011 and the public launch was communicated on June 11 of 2012. What started as a technical experiment to get TFS running on Windows Azure eventually evolved into a new product which also completely shifted the release cadence for new Team Foundation Server releases. More info on this in one of the next paragraphs.

The cloud version of Team Foundation Server provides (small) development teams easy access to ALM features (Version Control, Agile Collaboration and Automated Builds) without having to install and manage the server application on-premises. Not all existing on- premises TFS features like Reporting and Lab Management are available in Team Foundation Service, but it’s clear that this offering is quite compelling for small companies that want to be instantly up-and-running with the foundations of Application Lifecycle Management.

The Git Story

Also in 2012, Microsoft announced (basic) Git integration with Team Foundation Server via the open source Git-TF solution (http://gittf.codeplex.com/) which offered a set of cross-platform command line tools (running on Windows, Mac and Linux) for sharing version control changes between TFS and Git. Instead of building their own Distributed Version Control System (DVCS), Microsoft decided to embrace Git (the most popular DVCS solution on the market) even more when it was publicly announced in January 2013 that Team Foundation Server would host genuine Git repositories and Visual Studio would get native Git support for managing local and hosted repositories. I remember Brian Harry introducing that idea in a private NDA event at the MVP Summit in February 2012 (almost a year before the public announcement). There were mixed opinions internally in the TFS product team, but for the Visual Studio ALM MVP group it sounded immediately as the way to go: adopt the best DVCS solution in the market! I’m still very glad Microsoft eventually took this decision because it’s nowadays actually adding extra value for DVCS workflows in Visual Studio on top of Git instead of playing catch up with Git by building their own “Microsoft” DVCS solution. Git didn’t have the best client development experience on the Windows platform in the past, but with the Visual Studio Tools for Git, developers are getting native support for managing Git repositories inside Visual Studio and they could also target hosted Git repositories in Team Foundation Service. Including Git in the broad ALM vision of Microsoft resulted today in an integrated enterprise-ready ALM offering with Git: version control, work item tracking and build automation. It’s good to see that Microsoft is now actively working together in the open-source space to provide the best possible experience for software developers and it strengthens Microsoft’s presence on non-Windows platforms.

TFS Shipping Cadence

As from the beginning, Team Foundation Server has been a boxed product which had a 2 to 3 year release cycle. Bringing TFS to the cloud started a new unknown era. Rolling out fixes/updates for an on-premises product or for a cloud service is totally different. Imagine a cloud service which doesn’t update for a long period of time. People would assume it’s dead and forgotten. Customers of TFS in the cloud expect the product to evolve much faster than a boxed product and a service in the cloud must always be “on”. Delivering small and big updates to Team Foundation Server (different on-premises versions + cloud) was a big challenge for the TFS Product Team, but they managed to get it aligned pretty well now. Team Foundation Service will always be the front-runner and is updated every three weeks with features enabled/disabled by feature flags. Many features you will detect in the cloud may not be present for quite some time in the version of TFS you are running on-premises. On average, updates to VS/TFS (on-premises software) are pushed in a quarterly update and new major versions of TFS will be released yearly.

Part VI will cover the latest release of Visual Studio and Team Foundation Server: VS and TFS 2013. Stay tuned!

Part VI: TFS 2013 and Visual Studio Online

Part VII: Conclusion