Microsoft has had several really large, multi-faceted products in its history that eventually hit a wall and were broken up. Site Server is a prime example of this. When it broke it spawned SharePoint, Commerce Server and BizTalk Server, along with a few other less-famous and long-lived server products.
The Visual Studio Online path might just prevent this fate for TFS, since these regular updates become a boon in the Software-as-a-Service model. Satisfaction with the SaaS model often comes down to control and your ability to let someone else drive. If you are the kind of person who lets your phone and other technology update whenever the vendor behind it decides, then Visual Studio Online may be a comfortable place to operate provided it does everything you use in TFS. The big advantage is that Microsoft will slip the newest features into the platform weeks or months before they are available to on-premises TFS customers, even if they apply updates and new versions as soon as they come available.
Getting Set Up
The on-premises Team Foundation Server and cloud-based Visual Studio Online both require a code productivity client such as Visual Studio, though Eclipse can play too, so there is no advantage one way or the other there. We can therefore consider functioning installs of Visual Studio or Eclipse as table stakes. For our discussions we will focus on integration with Visual Studio. Team Foundation Server has provided a great deal of choice in how to proceed in getting your on-premises infrastructure going from the limited but nearly effortless setup of TFS Express to leveraging a legion of servers in various roles to support an army of developers. There are also a number of spots in between these extremes with the single server deployment being a very popular configuration.
Even this simplified configuration, though, has some hoops to jump through in order to gain some additional features over the TFS Express system. Start with a server such as Windows Server 2012 R2 and install a later version of SQL Server such as SQL 2014. Include both the database engine (as the default instance), the Analysis Services and SQL Reporting Services. The lighter version of this implementation skips SharePoint integration, as that blows out the hardware requirements substantially as well as the management load. After that the actual install of TFS is quick and easy, but now you have a full-blown SQL Server to care for, and without a full- or part-time competent DBA, that can be a burden or even worse: a ticking time bomb.
You likely know how the other side of this argument goes already, because Software-as-a-Service offerings like Visual Studio Online take every chance to emphasize it. With VSO, there is no SQL Server requirement, SharePoint or even Reporting Services, as things like that are up in the cloud hosted by Microsoft. Naveen Kohli, Enterprise Software Architect at CRA International and author of “ADO.Net Reference Manual,” discussed his experience with VSO after many years of using TFS. He said, “Currently we spend lot of time in managing infrastructure related to TFS. When we migrated some of the projects to VSO, I noticed that we are spending our time on development and less on TFS management.” He went on to add, “This benefit becomes significant where an organization does not have separate resources to manage TFS and some of the development team members are having to spend time in TFS management.”
The VSO Difference
Once an organization decides to make the move to Visual Studio Online, whether or not they are coming from using TFS, the task of transferring projects into VSO has to be planned. The reason is that according to Adam Cogan, president and founder of SSW, a Microsoft Regional Director and Microsoft MVP in Visual Studio ALM, “when an organization decides to move from running their own TFS on-premises to VSO in the cloud, they cannot just flip a switch, push a button or even back up then restore and be in the cloud.”
For this part it could be an advantage to not have invested heavily in TFS customizations in the past, because VSO does not currently allow for customization in the way that TFS does. Without the ability to do these kinds of customizations in VSO you are stuck with using the system as built, but the ability to do TFS-style customizations is likely coming in some future update— though there is no official word on that thus far. For this and other reasons, Cogan advised that it is usually best to start your use of VSO with a pilot project and avoid the urge to have the entire history brought over for a big project as a first experience. Running both systems in parallel is a great way to make sure the transition will work without burning the bridge in case a retreat and re-plan is found to be in order.
Thanks to SQL Server Reporting Services being part of TFS, creating custom reports on virtually any aspect of the system is within reach. Paradoxically, there are no reporting services in VSO; instead there is out-of-the-box reporting that Microsoft is incrementally improving in each round. SharePoint is also missing from the VSO scene, accounting for a major chunk missing from the offering. Yet Cogan observed, “Surprisingly for my SSW developers and our clients, missing support for SharePoint and SQL Reporting Services has not been the adoption blocker for VSO I assumed it was going to be.”
For an idea of just how far diverged TFS is from VSO at any given moment you can check out this page.