Adding TFS 2013 User Story Points field in Microsoft Project

Although we are an agile shop we still have a few managers who like to use Microsoft Project.  There is no project server setup to integrate with Team Foundation Server.  As of now the manager would like to export from TFS into MS Project, update, and import back in.  

Once the data is in project he will setup dependencies and other linking project managers like to do.  With the goal of producing a Gantt chart to help with dates.  They already have this by working with the velocity and burn down charts so I believe the main benefit is the setting up of task dependencies and making those visible.  I haven't found a good way to do this in TFS yet (sibling links don't stop you from completing a task before a dependency.)

Project uses field mappings between TFS and itself to define what fields show up in Project and which are editable.  One of the fields the project manager wanted to be able to update is StoryPoints.  As luck would have it this is not one of the default fields that show up.

This Microsoft article gives some explanation to the TFSFieldMapping file and how to download and upload it to TFS.

I followed the documentation and went with the advice of the project manager to add the field as ProjectField="pjTaskText20".  I learned a few things by doing this.  When trying to upload I got this message:

TF233004: You must install Office Primary Interop Assemblies (PIA) in order for Team Foundation Server to validate the Office Project Field Mapping file prior to upload. To install PIA, go to the Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=168855.

I went to Microsoft's site and found the Microsoft Office 2010: Primary Interop Assemblies Redistributable.  After installing this I got the same message.  The internet certainly makes work easier.  After some searching I found a post that says this doesn't work.  What you really need to do is install MS Project.  Hopefully for the reader you have this available to you.

On the next upload attempt I did get a little further.

Connecting...

Validating...

TF233003: Cannot upload the specified file as it either contains invalid elements or the elements are not in the correct sequence. Correct the Team Foundation Server Field Mapping file and try again.

Error detail:

TF234001: Work item field Microsoft.VSTS.Scheduling.StoryPoints is mapped to the wrong field type in Microsoft Project. You can map work item fields of type Double only to Project Cost, Duration, Work, and Number fields. Map the work item field to a Microsoft Project field of type Double.

Again I turned to the internet and found a better article.   What I needed was to define it as a Number (I guess that suffices for type Double.)

Columns displayed in Project depend on the predefined TFS - MS Project work item field mapping. To make Story Points show up in MS Project, you have to customize the Project-TFS mapping file since Story Points are not mapped to a Project field by default.

1. From the VS Command Prompt, run "TFSFieldMapping download" command to get the mapping file locally.

2. Add a new entry to the file to map your Story Points field to an MS Project field (pjTaskNumberx)

3. From the VS Command Prompt, run "TFSFieldMapping upload" command to push the mapping file back to the TFS Server.

From <http://social.msdn.microsoft.com/Forums/vstudio/en-US/9a2bcf3c-593c-4e62-9e7f-6f72fc0be523/ms-project-and-story-points?forum=tfsgeneral>

This worked like a charm.  Below is the command I used for the download and what the tfsfieldmappingfile looks like with my addition.  As always you should keep a copy of the original field mapping file (in TFS) and check in any changes to it.

I hope this helps you in your quest to be the best TFS admin that ever walked the earth!

From C:\Program Files\Common Files\Microsoft Shared\Team Foundation Server\12.0 I ran:

tfsfieldmapping download /collection:http://tfs/tfs/mycollection/teamproject:myteamproject/mappingfile:C:\WS\TFS\myteamproject\myTFSworkspaceSoICanKeepTrackOfMyChanges\TFSConfig\tfsfieldmappingfile.txt

Visual Source Safe migration to Team Foundation Server 2013

Below are some of the steps and the process behind migrating our ancient Visual Source Safe repository into TFS 2013.  Hopefully this will shed some light on things to think about before and during the conversion.

The first thing was to get my hands on the VSS Migration Wizard.  This was out on Microsoft's website. 

http://visualstudiogallery.msdn.microsoft.com/867f310a-db30-4228-bbad-7b9af0089282

This tool recommends having it local to the server where the VSS repository is located.  What I decided to do is spin up a virtual machine with SQL for this migration task.  Note that for large VSS repositories you may need SQL Standard or higher and not SQL Express.

Our VSS database was on a network file share.  This is the typically setup for VSS.  To get it to migrate quickly I used Robocopy to copy the whole structure to the VM where the migration tool was installed.  This not only gets it local (like the wizard wants it) but it also preserves the original VSS repo.  The only thing I changed in the SourceSafe config file was the location of the log file.  The log variable was still pointing to the network share.  After that I was able to log in with no issues.

The preservation was needed because A) it hasn't had analyze run on it in years and B)it was on a version of VSS not supported by the wizard.  I figured out the second part by running the wizard and having it verify things for me.   We were on 6.0 but I think it needs to be 6.0 c or d or higher for it to work.

The next step was getting past the verification.  Luckily someone had placed the Visual SourceSafe 2005 ISO out on our network.  That was a life saver as it is very hard to find old Microsoft releases.  This I installed on the migration VM where the copy of VSS repository lived.  I followed the VSS 2005 upgrade instructions included with the media to get the copied repository upgraded.

With the upgrade done the wizard worked like a charm.  I did setup a new TFS team project just for this repo.  The wizard took about 7 hours for our 2 GB VSS repository.  There were 73 file conversion errors.  They were all listed in the log.  Upon looking at one of the files that erred in TFS it was just a 0 byte file but it did exist.  The VSS file I was able to get with no issues and placed it on the tip in TFS.  That will have to work as I can get through these files quicker than trying to figure out the issue and resolving it.

Some of the other issues it ran into was files that were checked in with the 8.3 DOS file format/length restriction.  There is a Microsoft documented workaround the migration log points you at to resolve this.  For me it was files that were accidentally checked in (like log files) that were not needed.

This conversion was just to preserve it for historical purposes.  I am not actually building anything from it so having a few errors is OK.  I have all of the valid files in SVN right now which I will be converting to TFS soon.

If you have any VSS to TFS stories to share let me know.  I am always curious as to what others have done.

TFS 2013 Merge Tips

We did our first team merge last week.  There were several things we learned about doing merges of your whole branch.  Below are some of the learning's and any helpful links we came across for our next merge.

White-space

At some point one of the developers ran an application that reformatted the code.  In doing so it removed extra white-space in various places.  This caused a large number of files to not automatically resolve and where presented as conflicts.  We are not sure why but since the white-space was different on both branches this flagged the file.

This article found on stackoverflow.com was detailed enough to show us how to get around this however the code would be different between trunk and the branch.  The right thing to do would be determine which format was correct and accept the files on that branch.  In our case it was the source branch so we went through the several hundred files and accepted source version for those.

Ignoring Folders

There is folder we call Global that has files global to all solutions (files in the folder are references by each solution or project).  There are also build scripts in it managed by my team.  We do not want the developers to attempt to merge these folders without my team reviewing the changes.  Once we had a developer change a global file not knowing what global meant and a bad change was propagated to all solutions.  This caused confusion and delay.

You could have the team doing the merge ignore the folder by using the command-line and using the /discard parameter.  This is where I found that on stackoverflow.com.

We decided on another path.  With TFS source control permissions we can set it so that the teams cannot merge certain folders and/or files.  So when they do the merge it will give a permission error and not attempt to merge it.  This way they don't have to remember what to discard.  The other benefit is if they want to modify a global file it will have to be reviewed and changed by the build team.

Merge vs. Edit

During the merge session the pending changelist was still quite large.  They team was worried that builds would be kicked off by the system for allot of applications that had no changes between the branches except for files that we ignore.  What we noticed in the pending list were two key words.  Some files just had a merge and some had merge,edit next to them.  Doing some digging the merge means it is just creating a merge record but not checking in a new version of the file at the destination.  While merge,edit has both a merge record being created and a new file version being checked in (which will trigger a build).

When TFS Administrator Is On Multiple Teams

Working with Team Foundation Server permissions can be tricky when Deny is the king.  We have recently run into this when one of our administrators is also a member of an active directory group we use for development.  By default each TFS team is a member of the Contributors group.  Because of how we lock down root structures this has locked this admin out of several source code locations.

So for the area they need access to they are a member of the Project Administrators group and the Contributors group.  Both permissions on this area are being set through inheritance.  As an administrator you get all inherited allows.  As a contributor this area has been locked down as it has password information stored.  Thus a contributor gets a deny on read.  Because this is a deny this takes precedence and the administrator gets a permission error when trying to get Latest.  Well it is not really an error but it says all files are up to date but it is grayed out.

The Solution

This is becoming more routine which may be a bad thing.  To allow access to the administrator you must stop inheritance on the area.  After than just remove the Contributors group.  At this point you don't really even need to set a deny on read for the contributors group because they have no access at all.  This allows the Project Administrators group's allow to kick in.  Note that once you stop inheritance what was once an Inherited Allow is not just an Allow.

Big and Visible boards in TFS

We have teams starting to use TFS to walk their boards throughout the day.  Previously they used sticky notes or whiteboards with cards.  During this transition some teams have a desktop setup that refreshes the electronic TFS Kanban board (User Story level and above).  Desktop was nice enough to setup a service account with a policy to prevent the screen from locking.  This keeps the Agile philosophy to keep work visible.

What's wrong with this picture?

Well if you add this service account to the team it becomes a contributor.  So anyone walking by now has complete access to the source code.  It probably shouldn't as the purpose of the service account logged in for display is just for board purposes only.

Solution

You will need to explicitly deny this user any access to source control.  Since this may become more than one user I created a new TFS group called NoVersionControl.  This group is denied read for the team project under  the Version Control security tab.

This same group I set to have the same permissions as the Readers group so that it can view the board and test runs.

In addition you will need to mimic the Readers group at the root area for the team project.  Just go to Areas and right-click on the area.  Edit the security to grant Allow access to the NoVersionControl group to View permissions for this node and to View work items in this node.

You will need to buy a Microsoft CAL to be compliant since it is viewing Agile Boards.

Do you see a problem with this setup?