What is most valuable?
Version Control: TFS offers both the centralized “TFVC” version control technology as well as the distributed “Git” version control technology.
TFVC is a file and folder based version control system, which includes the ability to check-out, check-in, label, lock, branch, and merge. The security model is extremely granular allowing permissions to be set at the individual file, folder, or branch level (with inheritance as needed). The Git implementation is comparable to other on-premise Git offerings, such as Bitbucket and GitLab. The Git feature set has improved greatly between the 2013 and 2017 (latest) versions.
Build: The TFS build engine allows us great flexibility in how we perform our builds. While continuous integration (build on check-in) is used throughout the majority of the organization, we also leverage scheduled and manually initiated builds. The build workflow is entirely customizable and extensible to suit any need. Out-of-the-box build workflows in TFS 2013 are very NET-centric, however this has been completely overhauled in the 2015 and 2017 releases of the product. The newer versions of TFS can be used to create builds for virtually any technology stack, such as iOS builds on a Mac, Android builds, Java builds on windows\linux, etc.
.NET API: The ability to hook into TFS with custom a .NET code via API calls is critical. It allows us to automate any and all version control and build operations that we need to. Custom tooling which interfaces with TFS is a major component of our DevOps strategy/code delivery pipeline.
How has it helped my organization?
TFS sits at the core of our entire software delivery strategy. Implemented and used properly, it provides a centralized place to store all source code and build information for the entire organization. We always know which version of the code is deployed to which environment and are always in a position to support the production code line. Custom automation surrounding TFS (via the API) has increased the number of code deployments we are able to perform 1000-fold in the past 5 years.
What needs improvement?
Not all of the functionality, which is exposed by the command line interface (tf.exe) is available in the Visual Studio GUI.
New files/folders added to a branch are not automatically picked up as merge candidates requiring merges to be performed at a higher folder level (annoyance).
A broader view of the system-wide TFVC permissions would be beneficial. Since the security model is so granular, it makes it difficult to pull effective permissions for everything in TFVC into a single report.
For how long have I used the solution?
I have been a user for ten years. I have been a System Administrator of TFS for eight years.
What do I think about the stability of the solution?
No. I have experienced no system outages in the TFS systems, which I built and configured myself.
Obviously, a poorly configured server/database instance will have stability problems. However, there is extensive public guidance provided by Microsoft on setup, upgrades, and migrations.
What do I think about the scalability of the solution?
No. However, my user base has always been relatively small:100–200 users.
How are customer service and technical support?
Excellent. Every ticket which I have submitted to Microsoft Premier support has been responded to very quickly. I have been put in touch with very knowledgeable engineers, and reached a resolution quickly. Post-incident follow-ups and surveys are also performed to ensure that customers have a quality experience.
Which solution did I use previously and why did I switch?
How was the initial setup?
It really depends on your use case. For a sandbox, you can have TFS up and running with a SQL Express instance in about 1 hour. That’s not a production-ready system, though.
Performing initial (first-time) setups is fairly straightforward – getting properly spec’ed servers/database instances, following the install guide. Performing upgrade/migrations can be complex depending on how much customization that you have to the product and what has changed between versions. If you have a lot of customization, then the upgrades are going to be complicated.
What's my experience with pricing, setup cost, and licensing?
Use the Microsoft recommended “seat-based” licensing model. This allows a single developer with multiple machines to consume only one client license.
Which other solutions did I evaluate?
We recently looked at moving to GitLab. We chose not to do this because we already have millions of lines of code hosted in TFVC and migrating all of that to Git would be a daunting task with very little value. Since both TFVC and Git are now available and since the feature set is comparable to GitLab, we opted to stay with TFS. Development teams can “choose their own version control technology” between TFVC and Git.
What other advice do I have?
Hire a TFS expert or bring on a consultant. Nothing will ruin your development shop quicker than a poorly implemented version control/build system.
Microsoft premier consulting services is very expensive, but they can typically get you setup from soup-to-nuts in three to four weeks. That will include extensive guidance in how to use the tool. Your internal resources should work very closely with any consultant as a learning experience.