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.