Microsoft describes its Visual Studio Online offering as being “based on the capabilities of Team Foundation Server with additional cloud services.” Productivity across teams is a competitive advantage that is not just nice to have anymore, and a big key to productivity is providing the tools needed for Agile development. The drive to do more, faster with less resources is a powerful force and causes teams of all sizes to regularly assess their options.
Visual Studio Online (VSO) is clearly the evolution of Team Foundation Server (TFS), yet, as we shall see, we are not yet at a point where it is automatically the right place to be. Developers are getting used to a pattern even if they have not noticed it yet. Technology evolves and gets easier and better and faster until it hits a limit that can only be overcome by doing something disruptive. The new path almost always has lost ground to the past way of doing things on one or more fronts and then over time catches up and surpasses the old status quo methods or tools. One common example of this is the recent work to bridge code across devices. Native code provides better experiences, but requires too much additional work if many platforms must be addressed. Using HTML 5 or other bridging strategies has increased code reuse, but often there are functionality sacrifices.
In this same way, there are situations where moving to VSO will be a sacrifice. As Microsoft evolves the offering we will likely see it surpass on-premises capabilities as TFS becomes less strategic and cloud offerings reach full maturity and market saturation. We are not yet at that point, as evidenced by the places where VSO is still playing catch-up with TFS and so there is still a choice to be made between the two Application Lifecycle Management (ALM) platforms offered by Microsoft.
The ‘What’ of TFS and VSO
SharePoint is often explained by its “Six Pillars” that help people understand the things SharePoint can help an organization accomplish. Similarly, there are a number of areas where TFS provides capabilities. Perhaps most famously, TFS—and now VSO—acts as a code repository. TFS subsumed the old Visual Source Safe (VSS) product and now offers Git as well as a more attractive option. The details on making the choice between Git and the standard code repository are a bit involved so we will handle that a little later.
The Work Item that is at the center of the TFS and VSO processes makes it easy to use Agile methodologies such as Scrum and Kanban for your software development. Build and deployment capabilities are important to actually getting the code that is developed out and usable, and there is also a strong test component enjoying solid Azure integration as part of VSO.
Finally, there are insights into all of these processes via SQL Reporting Services in TFS and through expanding reporting and charting features in VSO. While Microsoft may be happy to have you use the offering for the entire development lifecycle, it is rare to find an organization that has not taken advantage of some plug-in or solution that makes their process better, by filling in gaps or by replacing something that TFS/VSO does because it can do it better.
Current Versions
Microsoft’s Team Foundation Server is a big product with many aspects and a lot of features. Benjamin Day, owner of Benjamin Day Consulting, calls it “the glue of Microsoft’s Application Lifecycle Management strategy.” As of this writing, the most current version of TFS available is Team Foundation Server 2013 Update 3, which released on Aug. 4. This update brought with it a number of bug fixes, feature additions and enhancements such as CodeLens support for Git, release management support for PowerShell and the ability to hide in-progress items on the backlog (see Figure 1). Just one month later, in early September, Brian Harry, a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server at Microsoft, announced that a Community Technology Preview (CTP) of Update 4 was available.
This coming release will bring Git pull requests for both Visual Studio and Eclipse, improvements to work management interfaces and many bug fixes and performance enhancements. Big products at Microsoft that have frequent updates are great for organizations that have dedicated IT staff and that have been waiting for the enhancements that come down the line, but for many smaller organizations or even departments in big companies, the treadmill of keeping things up to date is exhausting or even harrowing.
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.
As of this writing we see that not only are all of the new features to be included in TFS 2013 Update 4 already available as part of VSO, there are also a number of features, such as the ability to relate test cases to test suites and support for tagging in the Test Hub, that are slated for a “future update” of TFS but are already available in VSO.
Being based on Azure, VSO has some strong advantages over TFS when it comes to testing. CRA International’s Kohli said, “One of the things that has been biggest problem for us has been setting up load tests for our Web applications. We have always struggled setting up our test controllers and agents. Once we started using VSO and setting up load tests in VSO, it has been breeze to set up tests. We concentrate on setting up the tests and not setting up controllers and agents.”
Supporting this perspective, Cogan said, “At SSW we allow the developers to choose either VSO or our internal om-premises TFS. We see 80% of new projects going on VSO and only 20% choosing our internal server.” When asked if the developers understood the implications of the choice, he responded, “Our developers are aware of the missing features, but they really want to get the new features that the TFS team ship every three weeks to the cloud.”
Source Control Choices
Team Foundation Version Control (TFVC) has been available to Microsoft developers for many years in various forms. For those new to TFS, you likely know it as Visual Source Safe. The TFVC world revolves around check-in and is bedeviled by people having stuff checked out that someone else needs. There is also the problem of the code repository being the single point of failure, and when it is offline people get stuck with read-only copies of the files they need.
Overall this is a mature system with features like Check-In Policy, which lets you set rules such as requiring check-in comments or running the FxCop static code analyzer for .NET against the code upon check-in. You can think of this as the established way of doing things and it will be very comfortable to someone who has used some flavor of it for many years.
But the technology world has little respect for tradition when there might be a better way of doing things. Git has not been around all that long when compared to VSS, but it is quite popular and in many ways that newness is an advantage since it could be designed to avoid the issues TFVC has evolved.
Introduced with TFS 2013 and to VSO, Microsoft has made Git a more viable choice as your code repository for both TFS and VSO, with many feeling that Git is the heir apparent and the only reasonable choice going forward since it seems to be getting all of the new features. There does not seem to be any official word on this conjecture and it is certainly premature to declare the centralized code repository dead, but the best advice is to give Git a chance before going the other way.
In the spirit of ‘more and faster is better,’ organizations are often pushing to implement Continuous integration (CI) and Continuous delivery (CD). Continuous Integration automates things so that when a developer checks in code to the system, a build is automatically triggered, while Continuous Delivery takes the automation even further.
With Continuous Delivery (also sometimes referred to as Continuous Deployment) the system will automatically deploy the application to an environment where extensive testing can be done. Evolutions in cloud offerings are having big impacts in these spaces.
For example, there are big opportunities thanks to Azure Websites. Cogan said, “When using VSO and Azure Websites, you can get continuous deployment into action within hours. In one case we got a client down from four days to minutes.”
These are huge gains that mean more time is spent on producing great products and user experiences. It also shows that there are plenty of advantages to both of these practices and they are well-established in TFS, but there is still plenty of room for products to fill the spaces. Cogan said, “We use Octopus Deploy to simplify and automate our continuous deployment.” He justifies it by saying, “TFS Build is great, but you still need to deploy. Microsoft does have Release Manager but we typically use OctopusDeploy, which has a beautiful GUI and reduces the branching you need to do.”
One of the major challenges is replicating the production environment and avoiding the dreaded “works on my machine” response from developers when asked to confront a hard-to-replicate issue encountered in production. This is a space covered ingeniously by a company called Kubisys.
Soumen Chowdhury, vice president of marketing and business development, discussed how it has been put to work by some of Kubisys’ customers using TFS. The Kubisys platform is an appliance that allows organizations to replicate all or part of their production environment in a way that brings all the benefits of testing on production without any danger of interrupting or altering the production systems. To understand how this works in real life, Chowdhury shared the following anecdote: “There was a showstopper bug that only showed up when multiple users placed sales orders in the system at the same time. A Kubisys environment was created in order to find and fix the bug using an exact replica of the production system.”
These kinds of issues are very difficult if not impossible to reproduce in a normal test environment, as something always ends up being different enough that the problem does not manifest the same, if at all. Often an argument will break out over whether to debug on production (never a good idea). The advantage to this model is the code can be changed until it is proven to work in the Kubisys replicated environment, at which point it can then be deployed to the live production environment with certainty that it works in that exact environment.
Other Tools and Considerations
There is a huge range of third-party tools that fit well with TFS, and many take advantage of the highly accessible and customizable nature of the Work Item object inside TFS. One of these is TeamCompanion, which is an Outlook add-in for TFS (see Figure 3.) Cogan said, “We use Team Companion for email management and the product’s best feature is the ‘done’ button, which makes it easy to get early feedback from the Product Owner.” Another useful tool is Imaginet Timesheet (formerly known as Notion Timesheet). It is the first timesheet product that supports both TFS and VSO. Some of the most popular add-ons for TFS and VSO enhance the interface to the development systems by enhancing the interface of other tools, Outlook in the case of TeamCompanion and Visual Studio in the case of Imaginet Timesheet. The key is putting tools where developers are already working.
In the drive for greater efficiencies, development shops are pushing to stick to their business and let commoditized experts handle the rest. VSO fits into this paradigm quite well and offers some powerful incentives. For widely dispersed teams, the challenges of hosting TFS extend to security access to the system from outside the firewall. VSO is by definition outside your firewall and hardened by a company that knows quite a lot about being attacked.
CRA International’s Kohli reinforced this perspective. “Security and Intellectual Property protection has been one of our biggest concerns all the time. Now that VSO provides us the security that we need, it is one of the good things that has happened to us,” he said.
Microsoft has to be careful it keeps both its on-premises TFS customers and its cloud-based VSO customers happy as it supports both models with a similar, but eventually divergent set of features. The key to not getting pinched in the transition is to pay attention to how these two systems differ, and understanding that VSO is the future of Microsoft’s ALM strategy.
