What are the benefits of TFS 2010 for Axosoft OnTime?

Question

I am currently creating a business example for deploying TFS 2010 as our source code management and error / release management tool.

We are currently using OnTime for our bug tracking and subversion software for our SCM.

I was wondering what advantages TFS 2010 has OnTime?

I have still pondered and would like to hear the answers:

• TFS 2010 allows you to bind changeets-> work items-> builds
• TFS 2010 Provides More Workflow Customization Than OnTime
• TFS 2010 is integrated into the Visual Studio development environment - this requires fewer applications to open and fewer clicks

Thanks in advance.

Answer 1

First, I would suggest looking at what your main problem is , what is the problem you are linking to solve by deploying TFS.

In terms of access control v , I would recommend Martin Fowler's blog post on version control tools and the subsequent results of version control review. Admittedly, this may be the subjective representation of the subject, but it seems to be quite popular. TFS is clearly losing compared to other version control systems.

I am currently working with TFS2008, and we have migrated from SourceSafe and IBM ClearCase / ClearQuest, and there is no doubt that TFS is much better than any previous tool, but still has serious flaws, and the new version will only partially address those .

Addressing a single point that you raised:

• TFS lets you associate assemblies with change sets and work items, but there are so many other systems
• I did not use OnTime, but setting up a workflow can be both an advantage and an obstacle. Potentially, it may take a lot of work to create a user process template, and you still need a reasonable user interface (Team Explorer or web access may not be enough)
• Integration with Visual Studio is an advantage, but there are add-ins in Visual Studio that let you integrate with other source code providers.

I would probably mention the benefits of TFS

• Distributed assemblies and individual assembly agents - if you make many assemblies
• Full integration with Visual Studio with Team Explorer
• Extensive reporting infrastructure (although you can only use it fully when using MSTest for testing)
• SharePoint collaboration site for each project

Given the significant cost of deploying a full TFS installation, I would really think about what real business benefits would provide this solution with what others do not.

Answer 2

TFS is one of the least intuitive version control systems I've ever had to use. It may have many bullet point advantages over OnTime (and other comparable systems) in terms of raw lists of features and capabilities, but the key factor is whether it can fit into your workflows.

My experience with TFS is that you need to adapt to the TFS way of working, as adapting TFS to your path will be impossible or too difficult to justify.

Recently, we examined a number of possible alternatives for replacing a system containing SVN and a manual error tracking system (Excel spreadsheets). On-Time was appreciated, but considered too expensive and complicated.

In the end, we decided to continue using SVN, but we drastically changed (simplified) the structure of our repository and decided to combine SVN with the FogBugz problem tracking system. The integration between the two systems was rather rudimentary out of the box, but it required only a little effort on our part to achieve the much closer level of integration that we desired. Of course, much less effort than my previous experience using TFS .

Our SVN / FogBugz system is now also integrated with FinalBuilder's build automation kit.

The result is a system that is not only ideal for our work practices (because we have developed the means by which systems will be integrated to achieve this goal), but which also adapts endlessly as our work practices develop.

Answer 3

I think it really depends on the size of your team (s) and what you want from source control.

I used bugzilla in combination with Perforce for several years and found that both of them are really very good at personal things, working in a very small team (2-3 people), but suffer from the lack of integration between them and some small features, who took time to get used to.

I recently switched to a new job where TFS is widely used. This company has 4 main teams with 10-12 developers, each of which is divided into additional project teams, and it is in this environment that TFS really shines imo. In my opinion, these are the biggest advantages:

1) Integration with Visual Studio is not just a case of opening fewer windows, but it really speeds up your work and makes your life easier. Things like VS automatically check files for you when you work (no problems with random checks due to editing locks), the ability to synchronize local assemblies + TF, the ability to quickly compare the local version with previous ones. Third-party plugins for integration, but not one at this level and with the same stability.

2) Communication functions - simple things, such as integration with Live Messenger (with proper TFS settings), are great for large teams. We use WLM to communicate in the office and to work together as soon as possible than going to someone else every time you need to ask a quick question.

3) Linking assemblies / lists of lists to tasks - Yes, other SCMs do this, but again it is just done very nicely, integrated. I think this is nothing special for TFS, but I personally like the way it tracks it.

4) Easy merge / lock. I had experience with some other merge tools, and TFS works quite well, which makes merging after editing at the same time quite easy. This is very similar to perforce in this regard, but also with the usually quite effective automatic merge tool, which I use for small fixes, which, as I know, can not cause any potential problems with the changes that other developers are working on.

5) Building / construction management. Working with several large solutions containing 20-30 projects that depend on each other is a godsend. We queued it for assembly every 20 minutes, IF something changed, and when it happened, it is listed in the history log. It is also easy to see when you need to update local libraries.

I have no experience configuring it other than layout control, but I heard that this is the worst part of TFS. It's a little painful for everything to work correctly.

So, let's translate this into a business case. I would say that if you are a Microsoft product with a large number / several teams, then the time and performance savings that you will see as a result of the above functions are worth the investment in setting it up. It can be used in most cases, since you will probably have a subscription to MSDN (maybe some problems with CAL, but I'm not sure), so your biggest expenses will be associated with training and setting up users.

Answer 4

Don't beware of TFS, but the OnTime user interface is unintuitive. Also, I don’t like that you have different fields for "Errors and Tasks". Of course, you can always add your own fields, but the default layout should be ready to use.

We use only Errors, even if it is a task.

I'm not saying that this is a bad product, but if TFS now has a better user interface for bugtracking (which it had 4 years ago, when I had to use it and hated it), then this will be an argument for TFS.

Sorry that you want to get rid of SVN. This is a difficult decision.

Answer 5

I'm not sure about licensing Axios OnTime, but if you have an MSDN subscription, it does not cost extra. See blog post here

I use TFS 2008 only for version control, and although this is a good update from VSS, some of the things we do are not quite as expected. However, I wrote a small small web application that fills these gaps. It was fairly easy to develop against using the API and there were many add-ons to help with specific tasks.

Answer 6

This is probably not the answer you want to hear, but I would do everything to make a business example against TFS.

In any case, my general advice would be to try on your own (or in a small team) on a very small but real project - maybe you need some kind of tool on a one-time basis, a code that can be thrown away or easily transferred to another system, therefore that he is small. There is nothing better than using the system!

I used OnTime and Subversion. I did not use TFS as an error tracker, but I used it for version control. The initial part of the control is essentially the bad old Visual SourceSafe. If you are currently using Subversion, you will swear at you anytime you need to rename a file, or, God forbid, delete the file, and then create one with the same name - do not worry about branching or merging. It is difficult to convey in the message how primitive and fragile it is as a version control system - that’s why you really should use it. You will see what I mean when you get stuck in a file that you can neither check nor delete, as well as a meaningless error. Not that Subversion is great, but it's ten years ahead of VSS!

The part of the TFS workflow that I only played briefly with seems to me to be very "difficult." That is, it really restricts the user to this workflow and requires many steps that are often not needed. This material may help, but it can also interfere just as easily. A good system provides the workflow when necessary, but allows you to get around it when it just gets in the way. When we used OnTime, we found that even its relatively unobtrusive workflow was often just more of a problem than it was worth. Of course, it all depends on the specifics of your situation. How do you now use OnTime workflows and what do you want from TFS that OnTime does not provide?

Associating change sets with errors can be done using Subversion. It supports some extensibility mechanism - I don’t remember the details, but FogBugz uses it (we switched to it after OnTime). Linking to assemblies can be done by adding a simple svn tag command to your script assembly. Visual Studio integration can be done using VisualSVN .

Cost is also a huge disadvantage of TFS. It is very expensive for what he does, especially considering how well he does it. Yes, it's “free” if you still need to have an MSDN subscription for each developer, but you need it without TFS? Subversion is free, full stop. OnTime and FogBugz are much more reasonably priced.

Answer 7

I would highly recommend against TFS. Once I tried to restore the source code from the crashed instance, but I gave up after a few days, so the source code was lost (= it failed to do what VCS should do). Of course, I might have done something wrong, but it’s not easy to fix everything when the recovery guide lasts two miles, and it really is something that should happen so rarely that no one comes across it.

Now I'm using Subversion / Trac, which does the job (and setting up the workflow in Trac is so easy that it's not fun compared to TFS).

Answer 8

Avoid TFS for now!

I would stick with SVN + FinalBuilder and then choose between FogBugz or CounterSoft Gemini.