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.

A notable feature of TFS is its ease of creating user stories and tasks, which simplifies the process of adding and editing them. The integration with Azure DevOps also offers seamless functionality for CI/CD processes.

While there are always areas to improve, I am content with how TFS is structured now, particularly the Azure version. There might be some complexity in its off-cloud versions.

I have been using the repository component of TFS for at least fifteen years and the Agile management component since around 2012, making it between six to ten years.

TFS integrates well, especially with Microsoft Azure. I did not mention any stability issues.

I can't speak much about scalability, specifically regarding resource allocation across various servers and users.

I have used Microsoft's customer service and support, and I would rate it nine out of ten, as nothing is perfect.

Positive

We've used both TFS and Jira for Agile management. However, I find Jira a bit cumbersome compared to TFS, especially in time management where TFS offers more flexibility.

Integrating TFS with Visual Studio and Azure Cloud has improved our development processes by providing better integration and reducing errors, particularly when compared to Jira.

In addition to TFS, we use Jira for Agile management.

When targeting Azure for development, use TFS as it integrates perfectly with Microsoft products. Avoid using tools like Jira that aren’t as compatible.

I'd rate the solution nine out of ten.

We used TFS for our repository, maintaining the source code, and automating certain deployments from Dev to QA. We implemented automated scripts for testing. These are the main uses of TFS including versioning, product versioning, maintaining different branches for different clients, and having different code repositories.

Since we also use it for product management, release management is a significant aspect for product management companies. We have to ensure that the code and database are completely and fully maintained with all necessary components. Many of our team members use TFS because they use it for check-in and check-out of their codes while working, ensuring that nobody overwrites their code.

For test capabilities, it is always a mix. Where there is a licensing requirement, based on the number of licenses the team has, we utilize JMeter and Selenium. These are preferred wherever I had been, primarily because of cost reasons.

Version control is the most basic feature in TFS. It has been there since the beginning. We use it primarily for that purpose.

Basically ensuring that the code is not overwritten by other team members and maintaining the sanctity of the code. Bringing order to a disparate team which is virtual at different locations is very important, and TFS provides that control. Once you update a code, nobody can modify it until you are done working on it and check in.

It is a great product that revolutionized the way teams work together on Microsoft pieces of code. The versioning part has unique features and capabilities which are unmatched with other products out there.

From a testing perspective, while the build and deploy automation capability and pipeline integration are already present to a great extent, these are areas where TFS can improve further.

I have been using TFS since it was released, approximately 20 years ago.

The setup process is really simple and not complex.

This solution is based on organizational needs, not personal choice. There are different requirements that organizations need to address, and everything cannot be just TFS. Multiple checks and balances have to be in place where different tools come in handy.

For the purpose it was built, TFS does the job excellently. We have to look at the purpose of TFS. If Team Foundation Server is defined for something, then it should be used for that purpose. I cannot suggest adding SharePoint site capability or team project capabilities because this is a different tool. It has accomplished its intended purpose.

On a scale of 1-10, I rate this solution a 7.

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.

TFS has room for improvement as there have been global security issues that many companies, including ours, have experienced. There are glitches, such as runners getting stuck, deployments generating errors, and it's becoming outdated. 

TFS is not as fast, easy to use, or configurable as GitLab, despite moving into the cloud.

TFS has been used before my tenure, so the company has been using it for many years.

Its stability is lacking as we have encountered security leaks and glitches. Runners can get stuck, and deployments sometimes face errors.

I have never been involved with TFS support, however, as a Microsoft product, it might have limited global documentation or support options compared to GitLab.

Negative

We are in the process of switching from TFS to GitLab as TFS lacks the ease of configuration, cloud-based functionality, and security features that GitLab offers.

While I do not know the exact pricing, TFS is likely more expensive than GitLab.

I have used Google Hangouts personally, and as a company, we are considering GitLab.

TFS would benefit from having global tutorials or documentation like GitLab. The security issues should be addressed, and incorporating AI integration like Copilot could be beneficial.

I'd rate the solution six out of ten.

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.

Version control is excellent. Without it, all the development would not be possible.

From a reporting point of view, it could be more convenient for filtering and segregating. It could have been even better.

I would rate the stability a nine out of ten. 

There were over a hundred users. Everyone in the company used it. 

I had internal team in my company for support. 

I deal with many Microsoft technologies. In the last twenty years, I've been working with .NET. I started my career with Microsoft .NET 1.1 onwards. 

It's not complex. The initial setup is easy to understand and use. 

For the deployment process, we are purely using a CI/CD pipeline, and all our deployments are on Azure cloud.

TFS impacted the cost efficiency and productivity of our software development projects.

We used to use it for everything: planning, estimation, task assignments, tracking, source control, code review, branching, and merging strategies. Everything is wonderful.

I used the licensed version.  

Overall, I would rate it a nine out of ten. I recommend to use it. 

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.

If you've got 100 iterations and you create a new story and try to select which iterations, it doesn't default to the current iteration. You have to scroll right down to iteration 100 in the drop-down list. It would be good if it defaulted to the current iteration rather than having to go down a long drop-down list to select it when it's right at the end.

IBM ClearCase has something called a Version Tree, where you can see all the commits and updates to the configuration as a series of nodes in a tree diagram. You can also do mergers from the different branches using that. I'd like to see some kind of visualization tool for TFS that would make life much easier.

I have been using TFS for six to seven years.

I rate TFS ten out of ten for stability.

Hundreds of users in our organization use TFS.

I rate TFS a nine or ten out of ten for scalability.

The solution's initial setup is not too difficult. The people who set it up were experts who could quickly get it up and running. So, it looked like the setup was straightforward for them.

TFS is deployed on the cloud in our organization.

Overall, I rate TFS an eight out of ten.

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.

TFS should have capabilities similar to Git, like storing all types of artifacts in the repository. It should offer features that allow DevOps teams to track the changes made to the source code or by developers and generate automated reports and dashboards. This would make it easier to monitor and get information without searching through logs manually.

I've worked with TFS for more than three to four years.

Once TFS is installed, there are no major issues. I would rate the stability at seven out of ten.

The scalability is good because TFS is backed by Microsoft, allowing easy integration with other Microsoft applications. It supports a range of capabilities which can be utilized effectively. I would rate the scalability at seven out of ten.

There are some issues with the support team as we need to wait for a long time to get a response. The SLA needs to be improved. Direct communication, such as chat, to showcase screens would help resolve issues faster. I would rate the customer support at five out of ten.

Neutral

The initial setup was somewhat challenging, taking two to three days the first time due to our inexperience. We faced issues such as getting appropriate access and connecting TFS with our current environment. Once we prepared documentation, subsequent setups were easier and quicker, taking only two to three hours.

There are many version control options available in the market. From a costing and licensing perspective, I would rate it around six out of ten. It is not the cheapest product, but it offers good value for money.

I would recommend TFS to anyone planning to use it. It offers valuable features, though they need to be improved over time.

I'd rate the solution six out of ten.

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.

As an end-user, I expect the solution's performance to be faster while staying as stable as possible.

To be frank, we never considered the need for additional features in the solution. I don't have any specific suggestions for what could be added since the tool is already very streamlined. It is a stable tool without any issues; everybody in my company is happy with the solution. We follow a streamlined process at work with a specific set of steps from point A to point Z in a thorough manner. If there was something tedious, time-consuming, or repetitive in the solution, I could have spoken about what additional features I wanted to see.

I have been using TFS for a year. Also, I don't remember the version of the solution. I am just an end-user of the solution.

Since it is a very stable product, there is no chance of our company planning to replace it with some other product. The most that my company would do is they might consider shifting from TFS Version Control to Git TFS.

As I work in a bank, TFS ensures the solution is always available, making it a stable tool. I have never faced any stability issues while using the solution.

It is a scalable solution since TFS offers users a very good system, hardware, and efficient people to implement their tool. It is a very scalable software. Also, the scalability of software depends upon its hardware, and they provide very robust hardware.

The initial setup and implementation process of the solution was something that was done years ago in my company. Since I joined the company recently, I won't be in a position to comment on the implementation process.

We have an entire floor of people who provide technical support for deploying and maintaining the solution in our company.

I believe that my company has opted for volume licensing provided by TFS. So, it is not just one or two licenses my company has since my company trusts products from Microsoft. Though I am unsure, I think that if you purchase one of Microsoft's products, they offer you some of their other products for free. As per my knowledge, Microsoft products are cheaper than other products in the market. On a scale where ten is the highest and one is the cheapest, I rate the solution's licensing cost at one on a scale of one to ten.

Since in our company, we are already trained to use the solution, and so we never face any issues or problems while using the solution. The pre-existing features in the solution are more than enough to meet our needs.

The solution has a user-friendly interface. The solution already allows for more integrations with other solutions. Also, there is a separate team that works on the solution. The solution protects the systems in my organization. When it comes to the products offered to customers by TFS, they are constantly evolving since it has been in the market for twenty years. Also, we keep getting updates for the solution every second or third day.

I have a laptop, and if I start the solution on that laptop after two weeks or three weeks, I won't be able to connect. I need to take it to my technical support team. They will install some updates, and then I will be able to use my laptop. So, from this, one can figure out how much the solution has invested in their system. So, it is very rare that the solution faces any issues, and if any issues crop up in the solution, they have a very robust system of dealing with such problems. They have a good IT team that quickly resolves any issues. So, people are working to improve the system day by day. Every day, there is an evolution in their products. Some teams are working on production issues because of the new features implemented in the tool. Also, they are monitoring it continuously.

I rate the overall solution a ten out of ten.

TFS is useful for managing the code, such as code versioning, and managing where we store our soft-coding repository, which is where we can manage the versioning with the owner. The main purpose of using TFS is for managing our soft-coding, branching, and tracking of our different branches.

The most valuable feature of TFS is the central repository, and you can see what changes other developers did from which branch.

I have been using TFS for approximately seven years.

The solution is stable but could improve.

I rate the stability of TFS an eight out of ten.

We have approximately 10 people using the solution in my department. We might increase our usage of the solution. However, it is depending on if we add more users and if we receive authorization. We are focusing on accessing Azure Development, such as the task catalog that we have. There are developers who have full access to create and manage them.

I have not contacted the support from TFS. We have our own internal support.

The initial setup of TFS is straightforward. However, one should understand the concept of all the types of version control.

We used one person for the deployment of the solution.

I did not evaluate other options before choosing TFS.

I recommend TFS to others.

I rate TFS a nine out of ten.

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. 

The most valuable features are related to source code management. Using TFS for source code management and being able to branch and have multiple developers work on the same projects is valuable. We can also branch and merge code back together. 

Another valuable feature is our continuous integration because we do continuous builds. So, continuous building with the build server is also very important.

They have room for improvement in merging the source code changes for multiple developers across files. It is very good at highlighting the changes that the source code automatically does not know how to handle, but it's not very good at reporting the ones that it did automatically. There are times when we have source code that gets merged, and we lose the changes that we expected to happen. It can get a little confusing at times. They can just do a little bit better on the merging of changes for multiple developers.

When you restructure your source code, the historical information doesn't directly come across. It doesn't link when you move those source folders around. I would like to see that ability. The whole source code control system should show you the history of all the changes you made to a bunch of files. If we take a folder with a bunch of files and move it from one place to another, the history is gone. It just doesn't bring over the history of everything that was moved. That has prevented us from restructuring some of our source code to suit the larger number of developers that we have. I haven't called Microsoft to see if there is help that they can give me on this because on the web and on their sites, I can clearly see that that is just the way it is, and we're not doing something wrong. So, that is something for which I would really like to have the ability.

I can't recall the versions, but when I upgraded from one version to another, it didn't retain history as well because they made some fundamental changes. It might have been from 2012 to 2015. I upgraded and moved it to a new server, and it lost the historical information. We needed the old stuff running so that we could access the historical data. So, the upgrade path wasn't that easy. I don't know if that's the case anymore. When we go to 2019, we'll be finding that out.

We've been using TFS for 10 years.

It has been extremely stable. We don't have any issues with it. It works. Performance is good. All the features that we turned on are working exactly as we expected.

So far, so good. We've had one external developer consultant that had to come in and access it as well, and that went well. I don't have any gauge about how it would be for a team of 50 developers. The hardware we're running on it right now probably wouldn't be enough, but I don't feel that it wouldn't be able to scale to a larger number of developers. From a security model perspective and from a functionality perspective, it seems to have all the features to be scalable. I just don't know about the performance. That's all.

Currently, there are five of us who work with this solution. We have one project manager and four developers. We have one firmware developer who does not work in the Visual Studio environment. This firmware developer works in a microchip MPLAB X environment. All other developers work in the Visual Studio development world. So, it's more integrated, but both roles work. The same people also take care of its maintenance.

From a source code management perspective, it is being used very extensively. From a build server perspective, it is used extensively. We don't do release management with it, and we don't have integrated automated testing turned on in it as well. Those are two fairly large areas of functionality that we don't use currently. We may in the future, but we're not using them right now. We're using about 60% of the functionality.

From a technical support perspective, we've used the Microsoft website to get answers to our questions. It has been very good that way. I would rate it a five out of five in that aspect.

We haven't had to call a person or open up a case. We've been able to do our own self-support through the knowledge base that they supply. There are a lot of users of this product. So, a lot of the typical problems that people experience are out there, and it's easy to find them.

Positive

In different roles that I've had with different companies, I've used CVS, which is a different source code system. It's on the Linux system. It's not on Microsoft Windows. I've also used TortoiseSVN. I find TFS much easier because it's fully integrated into our solution.

In the previous world, I wasn't the decision-maker about which one to use. I came into projects that already had those in place, and they were not developing on the Microsoft platform. I understand why they didn't use the Microsoft platform in that case. In our world, we're developing software that runs mostly on the Microsoft platform, so it made sense to do that. Originally, when I used other packages, I was working as a consultant. I was working at different places, and I was using whatever the decision-makers used at those places as their source code control systems. When we started this company and I was the decision-maker, I used the Microsoft TFS platform.

It's relatively straightforward for a developer. On the initial setup, I'd probably rate it a four out of five. 

It took us about three days to get everything set up correctly, but we complicated our environment as time went on. We started off with one developer, then up to two, then to three, and then to four. So, as we increased our number of developers on the team, we changed the complexity of how it was deployed. It wasn't all done in one shot. It was done over a period of time. If we had to set it up from scratch today, it would probably take us about three or four days to map it out and do it correctly.

The more developers you have, the more complicated the setup has to be because you need to set up permissions and you need to set up roles and responsibilities. If it was just one team doing the same thing, it would be no different for one developer or five developers, but because we have different areas of expertise that we work in, we were trying to protect certain code bases from one developer from another. So, it just becomes more complicated. It's really just a security permissions thing that makes it complicated.

We did it all ourselves. We haven't outsourced. We have a company that we deal with that maintains our servers for us, but they don't have any TFS experience. We coordinated these changes through them, but we dictated the changes. So, they didn't provide us with any expertise.

We develop software for the oil and gas world. Our software runs right on drilling rigs and downhole and also on tools that we put downhole. When there are problems, we need to fix things quickly. It is critical. We're tens of thousands of dollars an hour at a rig, so we do need to make a quick fix. We now have release management and the ability to do small, hotfixes, and things like that to help customers. Definitely, time is money. It allows us to go back in time very easily to a known configuration in our worlds. We can go back with our source and pull out the code and compare and diagnose any problems that are occurring. It helps to rule out and diagnose problems quickly and way more efficiently in real-time. We remove the uncertainties of what software is and where and what has changed. It really helps us there. It helps us respond to our customers' needs in a much faster fashion and saves our customers' money in a way.

I believe we pay on a yearly basis. I don't know the current costs of them. We outsource all that to a third party. Each of the developers gets a Microsoft Visual Studio Azure DevOps license, which gives them access to the TFS server as well. We probably pay on average about 1,800 Canadian Dollars a year for every developer, but that covers a lot more than just TFS.

The cost isn't prohibitive. We use a lot of different software in our company. We use a lot of engineering software. If I compare the cost of our developer team software to some of our other solutions, such as our CAD package SolidWorks or our PCB design software Altium, we pay orders of magnitude less for TFS than we do for those other packages. Microsoft's licensing terms are also much better. They're good. I would rate them a four out of five in terms of pricing.

The only additional cost that you have is that you need to run it on a server, and you need a Windows Server software license. If you didn't have that to start with, you'd have to purchase it, but we already had that for other services within the company, such as file services, print services, etc. Other than that, there are not really any costs.

I'm always evaluating different things. The original Microsoft product, which was Visual SourceSafe, was something with which we had done some work in the past. TFS was the next release of that. I thought Visual SourceSafe had some shortcomings. I evaluated the difference between TFS and Visual SourceSafe and decided it was the right way to go. 

I've used Git as well, which is now becoming fully integrated with TFS. So, I evaluated that. I like a lot of the features of Git because of the user community that uses it. The open-source community highly integrates with it. TFS is now integrated with that as well, so I've had no reason to switch entirely off the TFS system.

Git is really a source code control system. The pro is that there is a very large component of open-source software that is supplied through the Git interface. A lot of developers of open-source applications expose access to their source code through Git, whereas Microsoft TFS is not like that. They don't do that. Microsoft TFS is more for internal. Microsoft TFS now supports Git, and it will use Git even as its underlying source code control system. So, TFS does integrate with Git directly now, and all the benefits of Git are now in TFS.

The only advice I would give is to design the security model and the developer model assuming that you have a larger team of developers than what you have when you start. You should set it up originally for multiple users to be working on the projects rather than having to change your methodology partway through.

We made some decisions on how we structured our source code and how we structured our team projects, and I would not have done that if I had known that the developers would be working on it in the fashion that we do now. Your configuration for ten developers would work with one developer too, but the configuration for one developer doesn't always work for ten developers. So, set it up for ten assuming that you're going to be doing that.

I would rate it a seven out of ten because of the issues with the upgrade path, restructuring folders, and things like that. If you don't configure it right to start with, it's a little bit difficult to change. That's the only reason that I'm not giving it a nine. If I have to make the same decision again, I absolutely would buy it again. It does what it was advertised to do, and it's not causing us any harm. It's doing its job, and it does it well. There are just a few things around the upgrade and around the restructuring of source code that could be improved. That's all.

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.

Nowadays, the shift is from Waterfall to Agile, so many vendors have come up with their own products. For example, Jira has many built-in features which support the PI planning. Overall, I think it would be useful to have something similar where Microsoft comes up with supporting concepts of scaling Agile in TFS so that clients don't have to look for a separate tool. That would be helpful.

With the latest version, I'm not too aware of whether Microsoft has implemented the PI planning features, the collaboration features, in TFS or not. But I think that would be one of the features that might be helpful to the development teams and for the overall planning.

There have also been some security glitches with this solution.

I've used this solution for more than 10 years. I've been working on Microsoft technologies only, and my team members have also been working on TFS for a long time.

The last time I used TFS was in 2020. After that, I moved out of delivery into consulting. I was using the last version before they moved to the cloud version, Azure DevOps.

Earlier, we were using it majorly on-premises. Later on when Microsoft introduced Azure DevOps, then we moved onto the cloud.

It is stable.

It's absolutely scalable. If you are planning for a high availability environment, then you can definitely have a backup environment as well. Then if something goes wrong with your primary server, there is always a backup available, which you can always use.

The support and documentation available on their website are very good.

I would rate them between 4 and 5 on a scale of 1 to 5.

I would give the initial setup a four out of five. It's not very complex. Microsoft provides all the documentation and guidance to do the setup, and even has videos available. The guidance is very good.

The length of deployment is on a case-by-case basis. Some of the clients may have a complex environment, some may not. So it depends on what kind of supporting tools are available on the client's premises. TFS is not that complex to set up, unless the environment design is very complex.

Most of the clients have their own support teams for incident management. So, it depends on each of the individual clients. They have the budget, and they will have an entire team to support your TFS and management.

It's worth the money. I've been using Microsoft products right from the start of my career, and I'm a big fan of Microsoft products. Many people don't like them because they work on different platforms. But the good thing about Microsoft products is that they're interlinked. For example, even if I'm a developer, the underlying development language is always going to be the same, irrespective of whether I use Dynamics 365 or ASP. The underlying programming language is always common. So, the rates are comparatively less than shifting from one Microsoft product to another, or implementing the suite of Microsoft products. The learning curve is always comparatively less.

Microsoft products are always expensive. Obviously, they are quality products, but it would be helpful if there was a reduction in price. But compared to other vendors, I think the cost is high.

I've been doing the budgeting for clients, and I find that the costing part — when we are going for new environments or we are ordering new servers — definitely plays a big part.

I would rate it between a 2 and 3 out of 5.

I would rate this solution 8 out of 10.

I'd give it that rating because there are security glitches, but otherwise, from a usability standpoint and from the operational perspective, I think the products are really good.