this week I participated a presentation of the 2008 TFS. Currently we are using Jira and Svn (and maybe Bamboo). What solution to you prefer?
TFS vs. JIRA/Bamboo/SVN [closed]
If you're just using TFS for source control and nothing else (which, btw, is overkill in the same way as chartering a jet to go pick up fast food), then you're better off with smaller solutions that just does source control (SVN, etc). TFS is an "Application Lifecycle Management" (ALM) tool, and incorporates a ton of additional functionality:
- Bug tracking
- Developer tasks
- External issue submission
- Automated builds
- Code reporting
- Project status update/time projections
- Many more
It's not really fair to compare it against tools that just do source control - TFS will appear cumbersome and expensive if you do. There are tools out there that can be used to do all these things, and they even integrate well together in most cases, but especially if your devs are all using Visual Studio (and there's always http://www.teamprise.com/ if some aren't) and you have some Sharepoint knowledge in-house, and ESPECIALLY if your devs have MSDN licenses (MSDN includes a CAL for TFS, so you only need to buy the server license), TFS can't be beat.
Jira + SVN + Bamboo does much much more than just source control. Comparing TFS with this stack is fair. –
Derina
... and yet that doesn't change: "TFS can't be beat" in the scenario rwmnau described –
Appulse
I am a big proponent of the open source movement and I make my living on Microsoft's products. The biggest issue I have always had when trying to get a company to implement TFS is the cost. I mean let's face it - free, functional, with a large group pushing out continuous updates, and a large body of products that easily integrate is hard to beat. For that reason I use CruiseControl.net, CCTray, NAnt, NUnit, NCover, NDepend, NDoc, SVN, Tortoise for my development environments. They just work together right out of the box. NAnt is so flexible for me that I can easily create custom NAnt tasks in C# and plug them right in. This allows to better perform database automation as part of my build process. NUnit, NCover, NDepend, and NDoc allow me to do deep analysis and reporting on my code base with each build done with each check in. This results of this analysis is sent out to the development team with each build. With successful builds I am able to migrate my changes upstream to my centralized development environment allowing managers to see how the team is doing. Having CruiseControl always touching and checking my code is wonderful. Using this I am able to automate all interactions between all of the environments allowing me to push code up or down stream. More importantly allowing someone no where near as technical as me to push code up or down stream.
TFS can perform many of the same tasks. However, it requires a lot more configuration and doesn't work with nearly as many third party tools. For me the the lack of flexibility is not acceptable (though I am sure that it will get there).
The opposite applies to some folks in that all of the tools I use are all third party tools. Each one is a separate download, install, and configure. Though I find this to be easy and painless (as it just works) this may be the stop sign that some don't want to cross...and would prefer to spend the bucks for an MS supported project.
@Appulse The OP doesn't even mention 'ALM' ¬¬ –
Rudolf
@Diego I think you are missing the fact the OP is comparing TFS with something else, ignoring ALM is like comparing a plane with a car and saying you can't talk about the fact the plane can fly ;) –
Appulse
@Appulse The thing is: the OP doesn't mention he needs to fly ;) I, for one, don't need this "processes guidance, integrated artifacts, metrics" stuff... maybe he's in a (happy) position like mine :) –
Rudolf
It's a matter of fair comparison / note that I've been in environments with both needs, sometimes you don't need it. But as everything it has a place, you need to know the full story to be able to tell if it fits the environment. The tricky bit is that the companies that need this the most "processes guidance, integrated artifacts, metrics, etc" rarely have someone that understands the need. All said, in my current environment we don't use it i.e. 1 week sprint pushing to production, craftsman like approach with seasoned well involved in the team. –
Appulse
Well just another answer only because the question includes JIRA too and this fact is overlooked by most of the answers. I think JIRA makes up the question not SVN alone.
It seems quite fair and interesting comparison. I have been big fan of SVN and Atlassian tools for past 4 years and continue to do so. Recently I joined another company which is still in process of institutionalization (as they say in CMMI) so we have a hot debate going on regarding the same subject. Most of the team is already convinced by the idea of SVN, CruiseControl, NANT and Atlassian (yes Atlassian is indispensable) excluding me. So as everybody in this thread is saying that the real comparison is for application life-cycle management not only source control so, what we really need for complete application lifecycle management (less project management), here is what I mean by that generally
- Source control - should be painless to create branches, tags, do code merges, and some times should also work over http
- WIKI - Program manager's heaven and developer's bible and notes area
- Bug Database - should be between programmer, program manager, QA guys and customer (yes so broad) this means cool user interface, tracking, and integration with source control
- Source code reviewer - must have, this is where Atlassian hits again (fisheye with crucible)
- Automated Builds - the more alarming the better it is
If you are going to use Visual Studio toolset and eco-system inside an enterprise, TFS is a viable option. It has deeper integration with the IDE and does all 5 things nicely. You get SharePoint sites for every project. However, if you are not going to use Visual Studio toolset or if the project is going to be public. Atlassian tools come free hosted in the cloud. They should be the go-to choice.
It really depends on your project and the enterprise. They are all good options.
It's a good point; the Atlassian products are very good, but if you're going to buy into their solutions to the extent that their combined functionality approaches that of TFS, you'll find the price tag matches TFS's as well, especially if you don't have MSDN subscriptions. –
Addressograph
@Faheem, you said "any good WIKI is not just good as full SharePoint site" ... are you kidding me!? SharePoint has got to be one of the worst products out there. It can't search its own content even if its life depended on it. It is light-years less usable than any wiki, even the bad ones! –
Houseclean
@Jeach, this is an answer from '09. Atlassian suite was not as robust back then. I have retracted the bit about SharePoint being better than a WIKI... I don't believe that anymore either. I consider the five points I have mentioned to be the main idea which can are not as ephemeral as the tools. –
Cooperate
If you code with MS visual studio for Windows, then the TFS will be the choice. If you develop in Java, then i would not choose any MS Product, simply because they are platform dependent. The Atlassian Product line for ALM is is great, JIRA&GreenHopper, Confluence, Fisheye&Crucible, Bamboo.. are nice Tools and easy to use and for small teams (<10) the price is a hammer. And you dont need any 8h MS brainwash to understand the Atlassian license system ;-)
We just installed the "Tool-Stack" in a test-project and we could immediately see the advantage and i'm very happy with the results i see. Nice integration with SONAR, i prefer Confluence Wiki over the Sharepoint wiki, the review tool crucible is expensive, but really usefull.
I dont know what TFS 2010 will bring - in term of function and cost - but MS license politic frustrates me all the time when i have to deal with it.
This is one case where you get what you pay for. It's worth the $$ for TFS if your devs use Visual Studio, the intergration is obviously going to beat out the others.
You also get the web access piece which can be used by clients/customers to create feature requests and log bugs without Visual Studio. And, you get the hooks into SharePoint 2007 team sites as well. TFS is so much more than just "source control" for devs.
I've already tried one 'source control' system from MS, I'm unlikely to try another.
I'm underwelmed by SharePoint's wiki.
That .net stuff they did wasn't bad though...
Personally I'd be concerned with the vendor lock in posed by TFS. I think that in this space there's still a lot of inovation to go and products like Bamboo and TeamCity are leading the way. TFS will invariably be playing catch-up no matter how tight their intergration with VS is.
How much does it cost to put TFS in place for a team of 100 developers?
As a comparison I think the full suite of Atlassian tools (JIRA, Confluence, FishEye, Crucible, Crowd, Bamboo) is around $20K, then throw in a couple of days of consulting and training and you're near the total.
For small teams, I agree that the Atlassian $10 for 10 users is near impossible to beat.
Disclosure: My company Consulting Toolsmiths is an Atlassian partner
The cloud version of TFS is free for up to 5 users. –
Vanillin
A couple of days of consulting and training ... that made my smile. The innocence of that affirmation. –
Fryer
I should have stated the number of hours in each day ;) –
Sacco
It's also worth seeing:
sTFS 2010 offers multiplatform support so you can use it from unix/Linux/Mac or Windows. You have to try it to see the advantages you get with TFS2010. It is a full ALM solution so can't even compare it with anything else that is not ALM tool. Regarding Teamcity and Bamboo, they provide only build related functionality which are no where near TFS 2010. TFS 2010 build using Windows Workflow and do builds on multiplatform machines is just amazing. I mean, you take test automation, from Coded UI, to just simple lab management (virtual and physical), and the type of reports you can generate that can help you in making key business decisions and improve your team's performance and processes, it is just awesome in TFS. Seeing is beleiving. Also, if quality of the software, processes, support, and money saved is important for your company, I highly recommend using TFS. In other words if the return on investment (ROI) and Business Value are a key factor, go with TFS 2010.
I spent 6 months working on a project to migrate a TFS 2008 setup to TFS 2010, and the build process was what made me begin to loathe the whole thing. On paper, it sounds a wonderful idea, and coming from a CruiseControl.Net background, I was looking forward to using WF, as it makes the build flow much easier to understand and follow. –
Addressograph
(continued) But... the implementation is very poor. Microsoft must have done a rush job on it, because the functionality, in terms of reuseable components, is very limited. When you consider what the community projects such as MSCommunityTasks and MSBuildExtensions offer, Microsoft obviously took a look at them and then ignored them entirely. For instance, there isn't even a task to copy files! You can make a call out to COPY.EXE, but that is so weak. Then to add insult to injury, if you try to author your own components, the process is ghastly, involving much messing around with the GAC. –
Addressograph
(continued) The one thing that I did like was that they made everything easy to test; but otherwise, developing WF controls was an exercise in futility. Small wonder that there are still no major libraries of components available for Team Build. The other parts of TFS are reasonable - in isolation, fairly average, but taken together they do build something greater than the sum of their parts. –
Addressograph
© 2022 - 2024 — McMap. All rights reserved.