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.

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.

For customers, we work in banking, finance, and healthcare domains, where there is a huge amount of data from customers and other types of applications and databases. We access this data for automation purposes. Many times, we utilize TFS for this type of thing.

Currently, we are focusing on the security features of TFS, such as the Credential Vault. We use it to store all credentials securely and provide access to specific stakeholders.

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 do a user story for a use case, which is like a snapshot of one pass through a use case. We tend to align them with the branches in Git. We have story branches created in Git and edited in TFS, which correspond to user stories based on a use case.

The solution's iteration board is good because you can track all your work with it. In TFS, you can do pull requests, trigger builds automatically, and gate them so that they're reviewed thoroughly before you release them. It is a good practice that makes things a lot easier.

We use TFS for forecast management.

The tool is sufficient for our business.

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.