InRelease and Team Foundation Server, tips for the setup

Recently Microsoft released a preview (non go-live, unfortunately) of InRelease for Team Foundation Server 2013. I am starting to have a look at it, so expect some content in the near future

First of all, the setup. You can even be the most important user in your network, but you would need to use the following command for the installation:

msiexec –I InCycle_InReleasePreview.msi

Otherwise you would get an error.

After successfully completing the installation you could go through some errors. Not too much to worry about anyway, I suggest you to keep an eye on the Windows Event Viewer (for IIS, InRelease uses a 32 bit Application Pool and it can be a trouble in certain environments) and on the logs into C:\ProgramData\

They are pretty useful as they are separed by component, so you would get an error log for the console, one for the server and one for the deployer.

Eventually here you can find a support page with the most common errors and solutions.

Enhancing Agile Portfolio Management experience with Backlog Mapping

Yesterday the Team Foundation Service team released the Sprint 50 build, and one of the features shipped is the Backlog Mapping.

Nothing too big or hard to explain: if you are creating a Portfolio within Team Foundation Service, you would surely get a flat list of Features and a flat list of PBI/User Stories.

With the Backlog Mapping (which is just a pane on the right side), you can drag&drop the PBI you want to be child of a certain Feature, and it is going to be automatically linked.

It is a very nice and effective feature, which combines a strong User Experience with a tangible result.

How the best practice made it into the product: Workspace Mapping in Visual Studio 2013

It is well known that the best practice says “One workspace per project”. Unfortunately it is not always possible to make it as the default solution, for various reasons (typical audience, etc.).

In Visual Studio 2013 the best practice made it into the product: the default Workspace Mapping is exactly one-per-project! In fact if you configure the Workspace for a new Team Project, you are going to get prompted to configure it:

After clicking Configure, you are going to map the Team Project root into a specific folder into your User’s folder:

It is definitely a good improvement, as it prevents the creation of a one, big, monolithic workspace which can take ages to download when needed, with all the related performance problems.

Some tips on adding other levels above the Feature

I know, I know – we have it on the MSDN. But I wanted to take the other route, which is not using witadmin and using the old Visual Studio 2012 with its Power Tools and limiting the raw XML editing to the pure essential part. It went pretty well I have to say. Let’s see…

First of all, download the Process Template you want to add levels above the Feature one (Themes anyone? :)).

When you’re going to open it with Visual Studio, you are going to see that both the Agile and Common Process Settings are empty.

This is because Microsoft changed the structure of the Process Settings, merging everything into a ProcessConfiguration.xml file. No worries anyway, we can fix it.

So, copy and paste the Feature.xml work item, renaming it to Themes.xml, and fixing the WORKITEMTYPE name:

Import it into the Process Template:

Now you can create a new Category using the IDE, and adding the aforementioned Theme. Use Custom.ThemeCategory as a reference name or whatever you may feel right for your custom category:

Now open the Theme.xml file. You have to fix the Implementation Hierarchy. This is very important in order to let you select Features as children.

Now, delete whatever it is not ProcessConfiguration.xml into the \WorkItem Tracking\Process folder, and fix the WorkItems.xml into \WorkItem Tracking:

Now, let’s add a node to the PortfolioBacklogs section of the ProcessConfiguration.xml.

It is enough to copy and paste the Feature’s one, but here it is very important to add parent=”Custom.ThemeCategory” to the existing Feature, in order to keep the linear hierarchy and avoid a “The following element contains an error: PortfolioBacklogs. TF401096: This element defines the hierarchy relationship between portfolio backlogs and must define a linear hierarchy from bottom to top. The specified hierarchy is invalid.” error.

Moreover, add a node to the WorkItemColor section, but remember to follow the existing colour pattern, otherwise the Process Template won’t upload. I used the same colour, but of course you can use others. Just keep in mind the pattern.

That’s all! Now you can upload your Process Template and you’re going to get another level above Feature with all the associated tools (board, etc.)