Why upgrade from Visual Source Safe (VSS) to TFS 2010?
Posted by: Subodh Sohoni
in Category Visual Studio, VSTS & TFS
Abstract: With Team Foundation Server (TFS), Microsoft introduced a much better mechanism for source control. In fact, TFS can do much more than just source control. In this article, I have listed 8 reasons to upgrade your SCM from Visual Source Safe (VSS) to using TFS 2010.
For the last 15+ years, most organizations doing non-trivial software development have used Visual Source Safe (VSS) for source and version control. On Microsoft platform, it is a very popular SCM. With Team Foundation Server (TFS), Microsoft introduced a much better mechanism for source control. In fact it can do much more than just source control. Being a Visual Studio ALM MVP and with many years of experience on working with both tools, It is my recommendation to upgrade your SCM from Visual Source Safe (VSS) to using TFS and here are the 8 reasons for that.
1. Set of Services:
While VSS offers only version control service, there are many integrated services offered by TFS. Services offered by TFS include Work Item Tracking service, Build service and Source / Version control service as foundation services. These services generate data. Based upon these foundation services, are the dependent services, which consume the data generated by foundation services. Those dependent services are reporting service and team portal service.
Reporting service analyzes the data generated by foundation services and provides reports based upon those. Visibility to those reports as well as other collaboration features are provided by team portal, that is based upon the SharePoint technology. TFS is not only a source control mechanism but a complete set of Application Lifecycle Management (ALM) services.
All these services are integrated by design, so you get additional benefits. For example while you are checking in code which is part of source control service, you can associate a work item like a task or a bug that you have fixed in that code. This association will provide excellent traceability between the work that is assigned to the team member and the actual code that team member has created against that work. This traceability is both ways. We can safely say that the services provided by VSS are only 20% or less compared to those provided by TFS.
2. Optimized for use over Internet:
VSS was designed in the days when internet was not a popular medium for teams to share work and collaborate. In those days, teams were primarily located at one place and communication and collaboration was not such a big issue. Today reality of life is that teams that work on single logical project are located at multiple locations and they use Internet for all communication including sharing the code between them. VSS was not designed for this reality and although it could allow the communication across the Internet for sharing source code, it was not optimized for use over the Internet. Design of TFS has been after the Internet has become popular for sharing and collaborating between team members. Services offered by TFS are designed and optimized for use over the Internet. For example, entire communication of TFS is done using tuned HTTP protocol. Source control service of the TFS is designed for minimum data transfer so that checkout and GET operations are by design delinked. Checkout does not transfer any files and that reduces the data transfer. Check-in process is atomic in TFS so that a situation will never arise that the dependent file has got checked in whereas it's dependency has not got checked in due to network snags. TFS utilizes the version control proxy in the scenario of multiple locations. This proxy enhances the performance and reduces requirement of bandwidth by doing caching of the files.
You may safely and efficiently use TFS over the Internet for intra team communication and collaboration.
VSS was designed for small to medium sized teams. It does not scale well over certain number of users accessing it concurrently. TFS has been designed for team sizes that may vary from small teams to very large teams where the number of team members may go beyond a few thousand. This is possible due to the three tiered architecture employed by TFS
It stores all it's data in Microsoft SQL Server 2008, it's middle tier is hosted as a set of WCF services whereas client tier is a set of objects that are encapsulated in Team Explorer. TFS is the only ALM suite that can scale out in clusters of Data and Application tier as well as scale up to support 64 bit multiple processors. This gives it virtually unlimited scalability. Even at the high scale of operations TFS provides excellent performance due to this architecture.
VSS depended upon the Filesystem to store data. It had limitations regarding failover mechanism and restoration capability in case of server failure. It also had severe limitation when it came to reliable transactional Checkin process. TFS stores all it's data in a very reliable data store - Microsoft SQL Server 2008. That makes it possible to have mirrored and clustered environment for data storage. In case of any failure, data is not lost, services keep on running and restoration in case of catastrophe is also easily possible. TFS implements two phased transaction based Checkin process. That ensures reliable Checkin of all the files that are attempted to be checked in or rollback of all those files to earlier stable state.
TFS is miles ahead in reliability not only compared to VSS, but also in comparison to other ALM suites.
VSS had it's own internal security which was based upon login and password credentials stored within VSS itself. TFS integrates either with Active Directory (Domain of the organization) or with Windows security. It supports NTLM, Kerberos, Digest and client certificate based security. It can communicate using HTTPS protocol as well as HTTP. These features makes it not only more tightly secured but also much more easy to manage too. TFS implements multi-layered security. It has Microsoft SQL Server Security for database service, analysis service and reporting service. On top of that it provides Source Control level security and over that is the TFS security that does not allow even listing of team project for users of TFS who are not team members of that project. Since TFS integrates with SharePoint service / server, it also integrates that servers security.
All in all, TFS does provide a very secure environment for the team to work.
VSS is notorious for data corruption and loss. It does not have a systematic and built in feature for backup and restore in case of any catastrophic failure. It is reported to suffer failures if the database size grows larger than a couple of GBs. Since TFS stores all it's data in Microsoft SQL Server 2008, backup and restoration of data are matured and systematic processes. It does not lose data even if database size may grow to terabytes. Pruning the database of unwanted projects, source files, work items and there attachments is operationally possible.
7. Process integration
Every organization has its own way of implementing the processes of their choice. They may decide upon which activities will be executed by various roles, which best practices of coding will be used and how the compliance to processes will be implemented. VSS has no way of either integrating in those processes or to provide customizability to adopt to the processes of the organization. TFS provides process templates for CMMI and Agile ( classical and SCRUM ). These templates provide out of box implementation of processes that are standardized. It also supports customizing and extending it's own behavior to suit the processes as designed by the organization that is implementing it.
8. Features of Source / Version Control
TFS offers many new features that makes working in enterprises more productive and qualitatively better. Concept and implementation of Shelving supports disconnected workflow of versioning. It allows temporary storage of source data on the version control server without affecting the build execution. It is also the bases for private builds and Gated Checkin which do not allow non-buildabale code to be checked in to the TFS repository. Checkin policies work like quality gates at the time of Checkin and also provide compliance to the designed best practices.
Branch visualizer allows us to view structure of branching and predetermine branches that can merge with each other. Source control of TFS implements Access Control List (ACL) based security. Every item in the TFS source control repository can have a ACL of it's own. It improves the flexibility and granularity of security implemented by TFS source control.