We’ve been using Delphi for 16 years, FB for 11 years, and StarTeam for 11 years. We’re looking to move from StarTeam to Team Foundation Server. I’d love to hear feedback or advice from anyone using this combination. I found posts from Lars Sondergaard and Mark Holbrook, unfortunately I can’t find a way to contact them directly.
If anyone is wiling to spend a few minutes sharing your experiences, please email me at jmrobertson at medevolve dot com.
Thanks!
Hi Jon
I’d love to know why you chose TFS at a time when many people are moving to distributed version control systems like git and mercurial? I can understand it to a point, in that TFS is much like Starteam, but I’m not convinced it’s much better.
As you know we deal with a multitude of version control systems every day, I have to say that TFS is our least favourite of them all, it’s a slow bloated beast, with a terrible UI. I cringe every time a TFS support case comes in, because I know it will consume 3 days just to figure out if there is a problem (doco is useless).
Just curious. For the record, we use mercurial here, and git for our open source projects (on github).
We would actually prefer to stay with StarTeam, but for various reasons that probably isn’t going to be possible. The short version is that MicroFocus has been completely unreasonable with our license costs in the past and we’re not willing to pay them a ton of money when they don’t even listen to our enhancement requests.
We make heavy use of Change Requests in StarTeam. We need more than strictly a source code repository, which is all git and mercurial provide I believe. We need a Change Management solution that is integrated with the source code repository. In this regard, TFS looks like it offers much more than StarTeam does.
I’ve heard and read horror stories about TFS and I’m reluctant to take this jump. That’s one of the reasons I posted my question here, as I knew there were at least some folks that had experience with the three critical components involved (Delphi/FB/TFS). But the workflow and field customization features are impressive. And the financial cost is right, since we’re a Microsoft Partner with Gold Competency.
I’ve already experienced frustration with the documentation, and I’m only in the very preliminary research stage. It’ll be months before we even start planning a migration, if we migrate at all. Fortunately, I’ve found some excellent posts from the community that are a little reassuring. Although Microsoft may not be able to explain how to use TFS, it appears to have a very strong and competent community.
Hi Jon,
I will reply here in the forum in case anyone else could benefit from my comments. If you need more details feel free to contact me directly at ls at t-doc dot com.
We were in exactly the same situation as you with Delphi/FB/StarTeam and switched to TFS about three-four years ago. We are also a MS Gold partner as you. (for those that do not know, Gold partners have free access to almost all MS products such as Visual Studio, TFS, Office, Dynamics CRM etc.).
We make software that falls under the “Medical Device directive” and as such we have some pretty serious requirements for “design controls” etc. This means that source control cannot stand alone but must be linked to requirements, test documentation etc.
As you, we were using StarTeam for this but I got fed up with way Borland was pushing out expensive updates that did not really contain any new features. From the “Whats new” of the latest releases I can see that they are still “milking the cow”. So we looked around for other solutions and decided to go with TFS as the price was “free” and it seemed to have the features we needed.
From a management point of view I am happy with TFS. I can enforce the workflow rules we have to comply with and at the same time make it relatively easy for all the developers to work with.
TFS comes with two predefined workflow templates supporting either CMMI type workflows or Agile. However, these are only starting points and can be customized a lot. It is a bit tricky to customize but we got good help from some of the quite many books you can buy. Also the VS ALM Rangers have a lot of useful info at http://vsarquickguide.codeplex.com/.
We used the CMMI template as a starting point and modified it to be more agile as we went along. TFS supports a lot of different “Work item types” but we only use the Requirement, Task, Bug and Test Case types. If you use the Agile template you can work with User Stories etc. instead.
On the practical level we use TFS to build up hierarchical requirement trees and then assign these to dev teams. The teams then create tasks and link these to the relevant requirement(s). The teams can also make sub-requirements as they go along in order to split up the overall requirements for easier development and testing etc.
Nothing can be checked in unless it is linked to a task that is again linked to a requirement.
Out designers can work with requirements and tasks via Visual Studio or via the excellent browser based interface. We also have TFS linked to Sharepoint and Reporting Server. This gives me dashboards about progress, backlog and a lot of other stuff. I also gives the teams their separate “team rooms” where they can discuss implementation details in a place where it gets documented and is easy to search. Sharepoint is also used to store all documents that are not directly related to development. i.e. stuff we don’t want user source control, but with Sharepoint you still get the document history built into that.
Our support department used Siebel CRM for support tickets until about a year ago, but we have now switched to Microsoft Dynamics CRM. We have an integration between the two systems so that we can turn support tickets into TFS work items and keep them “linked” without any manual work. We made the integration ourselves as both systems are Microsoft and have C# based API’s where you can do pretty much anything you want. If I was starting today I would probably have taken a close look at http://www.quantumwhisper.com/microsoft-crm-integration-for-software-development/ as they have more or less what we made out of the box.
Now to the developers. TFS source control has a lot of options to control if you want to use check-in/check-out, locking files when they are checked out etc. Until TFS 2013 we had it setup so that you had to check out a file before you could edit it, but several developers were allowed to check out the same file and would then have to resolve conflicts at check in. To make it easier to check out files we made a small command line tool that can be called from inside Delphi using the Tools menu. When called it will check out the “current” file in Delphi. If this is a form/datamodule it will check out both the .pas and .dfm file. It also handles .dpr/.dproj/.res in one go. (let me know if you would like a copy of it).
With TFS 2013 MS introduced “local workspaces”. When you use this you no longer have to check out files before you can work on them. You just edit the files and TFS monitors the changes and presents a list of what is changed. On my laptop I have a workspace with approx. 130,000 files and changes show up in the list in less than 1 second.
When ready to check in you assign a task to the changes, write a check-in comment and check it in. VS/TFS has a built-in tool for file comparison/merge but supports external tools as well. I prefer Beyond Compare so that’s what I have it configured for.
We do not use any of the source control features built-in to Delphi as they do not support TFS. Developers use Visual Studio for all TFS work. I actually prefer this as I find the source control features in Delphi to be lacking a lot compared to VS.
TFS also integrates directly into Windows File Explorer so when you browse a folder you can see the “TFS status” of the files directly and can perform various TFS related actions on them.
TFS also has an excellent feature where you can “shelve” your local changes to the server and give this shelve set a name. These changes are then not checked in but are backed up to the server. You can also use this to “park” something you are working on while working on something else and then “un-park” it again later. But other users can also “check out” a shelveset for code review etc.
With my developer hat on I find it quite easy to work with TFS. It is of course annoying to have to link check-ins to tasks etc. but this is not the fault of TFS but a business requirement that I find is well supported.
Once the developers are done with a task/requirement it is handed over to the testers. We do not use any of the “test” features in TFS, but as I understand it they are quite comprehensive. We use TestComplete for integration and UI testing so I have configured some TSF build definitions that are not really builds but launch FinalBuilder. FinalBuilder then launches TestComplete, DUnit etc. to actually run the tests. I also use FB to check in the resulting test logs back to TFS.
We also use TFS to start and record all builds. However, all the heavy build tasks are really handled by FinalBuilder. So a TFS build definition is configured to pass on some parameters to FB and FB then does the building. Once a build is completed we use TFS to keep track of build quality, release signing etc.
Some comments to previous post in this thread:
1. I find that the Delphi/TFS/FB combination works fine for our scenario. I have approx. 25 people working with TFS in total, but if your team is smaller or does not have use for linking code to work items etc. then this combination might be a bit “heavy”. The combination is also quite expensive if you have to pay “list price” for VS,TFS and Sharepoint.
If you take out FinalBuilder from the combination it would not work. It is really FB that provides the link between Delphi and TFS. I have tried to setup a smaller project we had some time ago without using FB. All I have to say is: Don’t do that unless you have a lot of time to waste.
2. You could compare TFS 2010 with StarTeam but with TFS 2013 this is no longer the case. To put it in Delphi terms StarTeam is Delphi 5 and TFS 2013 is XE7. And they keep adding new features at high speed. Try to follow Brian Harry’s blog for a while to get a feel for this (http://blogs.msdn.com/b/bharry/).
3. I have not worked much with distributed source control. I do know that TFS gets more and more of the same kind of features. Also TFS 2013 has support for using git as the underlying source control system. Not sure how it works in detail but you can find a lot of info about it on google.
4. Vincent mentions that he finds TFS slow and bloated. That might be the case compared to git/mercurial but compared to StarTeam VS/TFS is faster I think. I suggest you test it.
5. Stability wise I can only say that I have never had to restart the TFS server components in the 4 years we have used it. It is rock-solid in daily use.
6. Docs are not the best but there are lots of good books to make up for that. Also ALM rangers guides are good and as you mention the various forums can help out.
Sorry this ended up being such a long post, but I wanted to describe the scenario we use TFS in as this has a lot to do with why I recommend it. In other scenarios it might not be such a good fit. Also sorry if this looks like a sales pitch. I am really not working for MS :-).
Let me know if you need more specific info on anything.
Please, don’t apologize. Thank you very much. What you have implemented sounds like a dream scenario for us.
I can’t stand the old VSS mentality of requiring files to be checked out. Simultaneous development of the same source is one of the capabilities of StarTeam that I feel in love with. I wasn’t fond of the open source compare/merge tools that came with StarTeam 5.4. We use Beyond Compare and guiffy (an excellent merge tool). Glad to hear TFS gives us similar options. I’ve also had the “local workspace” feature on a wish list for a while now.
We also use TestComplete for testing, along with a little DUnit (and looking to migrate to DUnitX). We’re hoping to improve our automated testing processes and TFS may help with that down the road. But it won’t initially be a high priority.
While we are not required to link source changes to work items, I find it very beneficial to do so. The major feature of StarTeam that I don’t want to lose is Change Management and the ability to track source changes back to specific bugs/enhancements/requirements.
Our support team also uses CRM (also because of our MPN Gold Competency), so integrating those two as well sounds fantastic. Our finance team also uses Dynamics GP, and there may be a way to link to two in terms of tracking project costs.
We’ve had some off-site developers, including a small team of off-site developers at one point, but all source was maintained here. StarTeam worked well for distributed development. The communication protocol is lightweight and supports compressing the data for transmission. It also supported having distributed servers for improved performance, which would receive changes prior to being requested, so that a request did not have to make the full trip back to the central server. But we never needed to implement that capability. In terms of TFS, there are features that are lost when git is used, and we don’t have a need for git anyway.
StarTeam is fairly fast for us. Local refreshes can take a bit, since we have it configured to do MD5 checksums on nearly 7,000 source files. But that usually only takes a few seconds, which surprises me. I wouldn’t mind check-ins of large files to be a little faster. But over all, I’ve been very happy with StarTeam, at least the 5.4 version that we originally purchased. One of my biggest frustrations is that we were forced to upgrade in order to purchase additional licenses and we lost functionality when we lost the native Win32 client.
Posted By Vincent Parrett on 02 Dec 2014 03:29 PM
Hi Jon
For the record, we use mercurial here, and git for our open source projects (on github).
Our of curiosity, do you use anything for Requirements, Change Management, Resource Scheduling, Project Management, and HelpDesk? Are those systems integrated?
With TFS, we would be able to integrate Microsoft Project for Project Management, Excel for time analysis and charting, use Reporting Services for extensive reporting, Microsoft CRM for HelpDesk, and TFS itself for Change Management and Requirements Tracking. And these systems would be integrated to avoid duplicate data and, more important, avoid the time required to enter/maintain duplicate data.
I'm not sure yet how difficult or time consuming it will be to get all of that in place. I don't imagine it will be quick and easy. But with proper planning and following the advice of others that I've found online, I think it is doable. And the benefits for our team will be tremendous. That's the appeal. Right now we have too many applications that are not integrated and not kept in sync. And getting decent reports or analysis is near impossible.