TFS


At the end of October 2012, Microsoft announced the Team Foundation Service, not to be confused by Team Foundation Server (TFS).
This is essentially TFS online or TFS in the Cloud. You can create a unique URL for yourself and have 1 project up to 5 users for free. Any more of either and you have to pay extra for it. This will be a stable offering in 2013.

I have been looking for a source-control solution for some time now, and the only options were GitHub (paid for a private project, free for open-source) and BitBucket.atlassian.com (free, but you need a Git project). I do not want to manage a server, so Subversion or TFS was not an option.
In fact, BitBucket seems to be the only free option.

So, TF service was a welcome thing.
Note: The URL for it is: http://tfs.visualstudio.com and the old URL for tfspreview would be carried forward to this new one. The old URL will be deprecated. So, if you created your projects there, you will get them at the new URL.

Let’s say you want to delete a project you made. This is a no-no, as stated by the TFS team and they say a collection cannot be deleted. With a workaround, a Team Project can be deleted. This is not possible from the GUI (keep looking), but a simple command line command should do the trick.
To do this, go to the Visual Studio command prompt and let’s say you have a project called “foo” you want to delete. Type the command:
tfsdeleteproject /collection:https://foobar.visualstudio.com/defaultcollection foo

tfs capture

This deletes the foo project from the default collection. This is a complete hack and is insecure because no credentials need to be supplied. This also means that someone else could potentially delete your project, so be weary of this for now, and maintain a separate backup locally in case this happens and always think it could. I would expect this hole to be plugged in the near future, so don’t count on it to be there when you try..

http://blogs.msdn.com/b/bharry/archive/2011/09/19/deleting-a-team-project-from-the-team-foundation-service-on-windows-azure.aspx has this info.

Advertisements

It’s been a while since I wrote about TFS although a post I made about it 5 years ago is still the most popular post on my blog (weird!), and I’d like to give a plug for a plug-in for TFS called Urban Turtle, that provides SCRUM tools for Agile development. 
The name seems like a play on Tortoise, which provides integration for SVN (a source-control system), and I have this vision of a turtle walking in a city with shades on and a boom-box on it’s shoulder.

The Urban Turtle website is at http://urbanturtle.com/, and it has all the info and videos for you to get started.
Brian Harry of the TFS team has a good post about it here: http://blogs.msdn.com/b/bharry/archive/2011/01/05/urban-turtle-for-scrum-and-tfs.aspx

I am still exploring it, but it seems to have all the features you’d require in a SCRUM tool.

The SCRUM features are available in the Project Portal (website on SharePoint), for easy web-access to all team-members (including clients)

Creating Sprints, for example.

image

image

At work, we use TFS for source control and JIRA for SCRUM, but I don’t like the Printing possibilities of our JIRA setup, and assigning a Task to someone is not easy (because of a clunky interface with the name list).

Let’s see how things are in Urban Turtle land, and I’ll report back if I end up trying it.

Many people are having problems installing Team Foundation Server 2008 with an (existing) installation of SQL Server 2008.
The problem is that the TFS RTM 2008 does not support SQL Server 2008;
SP1 provides that support and you can get it from MSDN downloads, but SP1 only works over an existing TFS installation. So, this is a problem.

The workaround is to merge the setups to make SP1 an installable, with the steps below:
1. Copy the AT folder from the TFS install disk to your hard-drive, say C:\TFS_AT as the .
2. Extract SP1 to your hard-drive, the
Run the command from the SP1 folder: TFS90sp1-KB949786.exe /extract:C:\TFS_SP1
3. Combine installable and SP1
Run: msiexec /a \vs_setup.msi /p \ TFS90sp1-KB949786.msp TARGETDIR=
4. Run setup.exe from the

Source blog: http://blogs.msdn.com/aabdou/archive/2008/05/13/team-foundation-server-sp1-beta-now-available.aspx

To read more about the features added in SP1, check:
http://blogs.msdn.com/bharry/archive/2008/04/28/team-foundation-server-2008-sp1.aspx

One of the rare but critical tasks of Configuration Management is the unlocking of items locked or checked out by someone else, like an ex-employee or a developer in the Bahamas while an emergency patch needs to be pushed out.

Unfortunately, the unlock action is not available in the context-menu or a GUI but needs to be executed from a command line. I wonder why it’s not in the GUI, granted deleted files and pending changes will not necessarily be visible in the GUI but at least the Undo should be available for visible items while the command line still provides the all-encompassing functionality.

The help was not very clear, so I’ll simplify the command for you.

There are 2 possible options for unlocking, viz. unlock or undo (if checked out for Edit).
The respective command to use is tf lock /lock:none or tf undo

The parameters in both cases are the same:

filename (in the help topic, this is the itemspec parameter)
This is the file you want to unlock

/workspace: [user’s workspace];[user name]
The user’s workspace needs to be figured out…by right-clicking the locked item and selecting Properties… and then the Status tab
The user name is the fully qualified user name, in the form: domain/user

/s:[server path]
This is the TFS server in question. Typically it’s http://servername:8080/

So, a sample command would be something like:
tf undo $/Apps/Dev/file1.aspx /workspace:”Dev station”;corp1\ra /s:http://altair:8080

(You run this is on a VS client, at the Visual Studio command prompt)

 

Another command I found useful during the process was tf status /user:Joe /s:server path, which essentially lists all files locked by Joe. I piped it to a text file (with >> C:\joe.locked.txt) to get a report.

[edit – changed colon to semicolon above. Thanks for the feedback]

In order to provide non-Visual Studio users (like business folks and clients) access to the Matrix, there are a few options available from Microsoft and third-parties.

The two I’ve tried and will talk a bit about are Team Foundation Client and TeamPlain. There are other tools out there too, but I haven’t looked at them and don’t plan to. (Sorry!)

The out-of-the-box option offered by Team System is the Team Foundation Client, which is essentially the TF Explorer plug-in. But this requires an install on the user’s machine which is always an overhead, since it involves IT folks and help-desk, etc.

To address that issue (I guess), Microsoft recently acquired a company called devBiz which has a product called TeamPlain to provide web access to TF. It is a pretty slick-looking website product that hooks into TF at the back-end.

The TFC install did not work for me “as-is” from the MSDN DVD because the paths expected by the setup program are different from the actual paths on disc. Doh! The workaround for this is to copy the install folder on a drive and copy/move required folders as you come across the “not found” error messages. I came across 3 errors. Does this mean better QA is required?

The TeamPlain install went pretty well but fyi, it does need an install of TFC on the web-server hosting TeamPlain. (I’m guessing TeamPlain is exploiting some APIs provided by some component in TFC.). I installed TeamPlain on the TF server itself and some companies might have a problem with that configuration because it might pose a security risk, and for that it is possible to configure a separate web-server to host TeamPlain.

The UI of TeamPlain is pretty slick but I think it is too cluttered and could be dumbed-down for business users or maybe specialized for different users. I also got some crazy errors at times while accessing Source Control (SOAP exceptions for Network Service while authenticating) but these could be due to our network glitches too.
One thing that bugged me, but I understand that it’s a transition period, was the web pages that opened up when I clicked the “Buy License”, etc. links. They just take you to a page announcing the buy-out. How about letting me know in a nutshell about licenses (if I need them anymore or whatever) first?

I am playing with it at the moment and will write about any issues I come across later.

An important factor in using TS effectively is having the right Team Project design and having a solid plan for Configuration Management.

It is important to understand major issues related to projects and TS features because a bad design can cripple your development process, and you might have to start over.

A good starting point is to know the scope of a Team Project and what it contains, and to understand how branching and merging works with this. There are many good articles with related information but I have not come across any advice on a solution.

So, I’ll try to explain what I designed and why and leave you to read about Team Projects and merging/branching.

As you may know, a Team Project is a container for items like source control, work-items, documents, etc. What these items could be is configurable at a higher level with Templates (there are 2 provided out of the box). Project reports, documents, etc. are available at a Team Project level. Most dev teams work on a number of products which are maintained over time and enhanced over release cycles, mostly with parallel development. Instinctively, one would think of having 1 Team Project per Product and also maybe 1 Team Project per release in order to manage a release tightly and eventually do some merging across releases, etc.

Unfortunately, there are limitations of not being able to move artifacts like Work Items, etc. across Team Projects and one has to consider the implications of those before running off and happily creating Team Projects. It is likely that different products share features or a part of the code-base and bug-fixes or enhancements need to be propogated across projects. In most realistic situations, a bug (read Work Item) slated for 1 release may get pushed to another. Given the limitations and requirements, the conclusion is to have 1 Team project for the entire Product line, assuming these Products are similar and share features and the code-base.

The downside of this is that the Team Project is one mother-lode and granularity is lost at a product or release level. I hope the limitations are addressed in future TS versions, but till then one might have to customize Reports and other things to get information at a Product/Release level. If you have other ideas or workarounds, please post them.

Given the assumption of using 1 Team Project, I will talk about Configuration Management (branching/merging, building, etc.) later…

One major part of the VSTS project, is the migration of existing assets from VSS into TFS.

MSDN article: http://msdn2.microsoft.com/en-us/library/ms253060(VS.80).aspx

I wrote this post  over several weeks so as to group migration related stuff together, so don’t mind the changes in tense.

The initial plan is to only migrate the source code and assets of the App Dev group. We did some test runs during the planning phase and the idea is do this during the Test (QA) phase of a patch, viz. to lockdown VSS and ask developers to hold-off check-ins.

For us, the migration mainly consists of asp, vb script and some .NET 1.1 and 2.0 code. FYI, the type of artifacts do not really matter because the migration is file-based.

One of the key decisions made was around what items to migrate. We decided to leave the C++ code in VSS since it is being deprecated and rarely modified, but migrate classic asp code to TFS so that developers could use only one dev environment…to fix bugs in classic asp and to develop new features in .NET 2.0.

Another key decision was planning our target Team Projects and the related Configuration Management process, which I will write about in another post.

Before I bore some of you with details of the migration, let me jot down some lessons learnt:

  • Be aware of the differences between TFS and VSS (linking, labels, etc.)
  • Know the limitations of the conversion tool (labels not converted, etc.)
  • Plan your target Team Projects well. 
  • If you have a big folder to migrate, split the conversion into smaller chunks of it’s sub-folders. Have a small plan for the root files.
  • Work on a copy of the VSS database, so you can manipulate folders in there.
  • Do not do test migrations in the “production” TFS because there is no way to clean up clutter. Hopefully the “destroy” feature in Orcas will resolve that.
  • Plan to keep VSS around for a while as an archive and a reference (for labels, etc.)

Now, the details: 

We are using the VssConverter (command-line) tool for the migration. There is a GUI written for this (http://www.epocalipse.com/blog/2006/04/06/vssconverter-gui/) but  we didn’t really care about it. It’s a pretty simple tool that basically migrates a folder from VSS to TFS based on a bunch of settings defined in an XML file. It needs SQL Server (Express is fine) to store intermediate information as part of the process. Note that it also needs VS 2005 installed on the machine.

There are some caveats to this migration process, that you will need to consider depending on the layout of your codebase, because some features of VSS like shared or linked files are not supported in TFS. Our solution to that was to eventually duplicate these items and use them independently for now. The linked stuff makes it confusing anyway and the “right” solution for this (VSS or not) is to include files across projects.

One limitation of the tool is that History comments of files are migrated, but the timestamps are not; they are instead prefixed in the comments. The check-in timestamps in TFS reflect when those versions are checked-in into TFS (I assume the tool just uses the TFS API instead of hacking the original timestamps into the database).

This may not be critical but may be important if you’re doing some time-based analysis or sorting. 

 Also, an important to-do is to first run the Analysis option and map the VSS users to TFS users (in an XML file). (I do not know what user it defaults to for unknown users in TFS).

To isolate the migrated assets, I created a Team Project called Production and put in the stuff into a folder called Legacy. I did this with the idea of eventually moving “used” files into another branch so dead files can be weeded out.

This blog post giving good insight into the conversion implementation: http://blogs.msdn.com/ankur/archive/2005/09/14/466493.aspx

Network problems disrupted our migration and although the tool could resume a few times, the last disruption messed it up and it kept giving an error (I forgot what exactly) and I had to do some major hacking to complete the migration.

I ended up on the MSDN boards and finally got in touch with Ankur, who I think was the main author of the tool. He was a great help in pointing out things which were not possible in the tool and in TFS, so I had to do some very weird workarounds to convert the remaining files.

My major problem was that a large sub-folder was taking too long to convert and we had a network glitch each morning that threw it off and so I had to split it into smaller chunks for conversion. Although one can specify sub-folders to migrate, files in the root pose an issue since the conversion tool is folder based and not file based. So, I ended up making a copy of the folder in VSS and dropping all the sub-folders so it only had the root files and then specifying the same target in TFS. Note: I did try creating a new folder (project) in VSS and dropping (which created links) the root files in it. But then the tool would not pick up any history because they were linked files.

Anyway, our migration is now complete. I did a compare from the files in VSS and TFS and things look good. If you need help or advice about this, feel free to contact me.

Next Page »