TFS Reviews

We use TFS for our Agile board to handle our sprints, epics, stories, and tasks, tracking how work is progressing. It is also a repository for managing code changes.

TFS integrates seamlessly with Visual Studio and Azure Cloud, facilitating continuous integration and continuous deployment, which enhances the development workflow.

I've worked with TFS for source control and Agile project management. We also used TFS for seamless team collaboration and tracking. 

I used TFS for a couple of years. Now, we use Azure DevOps. It's a wonderful tool for source control and CI/CD pipelines.

It's a really valuable tool for development projects, especially. We can leverage TFS, or even now Azure DevOps, for the entire lifecycle process.

We use TFS for all of our source code. We develop a software suite with about eight different applications that work together, and then we also do firmware development. We use it for our firmware development source code repository.

It is deployed on a private server. We've gone all the way from version 2012 up to 2017, and we will be doing the 2019 upgrade very soon.

An example would be that now we have scheduled releases. We have scheduled builds that happen every Thursday that get rolled out to our development testers. In the past, before TFS, the developers themselves used to initiate that, and it was done randomly. So, being on a schedule is much better. 

It basically enforces our rules. Because everything is more controlled, source code cannot be checked in unless it builds correctly. It basically forces the developers to adapt to the agile methodology that we use, which is small chunks of work at a time. 

We use this solution mostly for our clients. It's a lifecycle management tool. We use it for the entire lifecycle of software development. Then we deliver it, and use it for production support. Basically, you can always use it for your requirements, as well as to track the health of your project.

I have found almost all of the features valuable because it integrates well with your Microsoft products. If a client is using the entire Microsoft platform, then TFS would be definitely preferable. It integrates with the digital studio development environment as well. So, almost all the features for TFS are useful.

The good thing is, unlike other products, you get a complete suite of features. Many of the other vendors don't have an entire suite of features available. If you take Jira for example, the requirements might be captured in a different tool. Or maybe there are other features in the lifecycle development environment and different tools might be used, but TFS offers a consolidated package. You don't have to go to other tools to capture your requirements, or maybe even if you're doing build and release planning.

It is easy to push our changes from quality to pre-prod and prod. We also use TFS for maintaining our data.

It is a repository, so all the changes are saved. Also, even if there is some conflict, we have the merge tool and can use it to check the changes made by the developers. We can finalize which one to push to the server.

TFS is used for version control. So, other software can integrate with TFS. The tool is also used for documentation and STLC.

Since it is a robust solution, I face no performance issues. Also, considering how well the implementation process of the solution was carried out, we never faced any issues while using the solution.

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.

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.

My primary use case is within the organization's work environment, which is mainly focused on Microsoft products and TFS as part of our corporate IT infrastructure.

TFS allows me to handle automated builds and release management quite easily. It is user-friendly with a straightforward drag and drop interface, which makes it easier for me to create builds and release pipelines without needing to program YAML files. This setup is especially beneficial to me compared to GitLab.