Configure Work Item Field as team field in Team Foundation Server

Recently, working on a customer, due to the teams and project structure they have, and the reporting needs for this structure (a correct structure BTW), we came to a situation in which dividing the Teams by areas was not so useful, and didn’t helped us in our work item and reports strategy, as you probably already have observed, it is not so easy to create the reports per team with complex structures, as areas are tree views.

So I came up to this article, which helped in creating a Work Item field to define the teams, I found it very useful for this and other situations, being honest, I find this even more comfortable than using areas for this.

For what is coming in this blog post I assume you already have knowledge about how to divide the work between teams in the same Team Project and feel comfortable with TFS Work Items personalization’s. Also this article is entirely based on Team Foundation Server On Premises.

Basically the procedure (go to the article for the details) is:

  1. Define a Global List for your list of teams.
  2. Add a new field for Features, Epics (the article doesn’t mention this first two but we also added to them=, Product Backlog Items, Bugs, Tasks and Test Plans. At the end of the day, any Work Item type which can be used to work in backlogs. It is important to define the field with the same name in all Work Item Types, and also be sure to make this reportable as dimension if you plan to use it in Reporting.
  3. Specify this field to have values from the Teams Global List as allowed values.
  4. Use witadmin command line tool to export the process, and modify the process to specify the new field as the field defining the team the work item belongs to. (<TypeField refname=”MyCompany.Team” type=”Team” />).

When you go to admin your Team Project (all of this is done at Project Level) you will see the possibility to define the value for the new field for each Team, so the backlogs and panels are filtered correctly.Make sure to specify this value for all of your teams, if you don’t do it, you will receive alerts about your team is not correctly configured. Also remember a particular team in TFS can own different values for this field, which is particularly useful for Product Owners views or management views.


Also, there is another point in the article, which allows you to be able to specify the team you want the Work Item to belong during its creation from the Product Backlog view, something like the next image. But this configuration brought me a small problem, when someone from within a team, selects to create the Work Item for a different team, the backlog view produces an error as is it weren’t able to save the Work Item, so I disabled this configuration.


And as for final conclusion of this, well I haven’t been still a lot of time with this solution in production let’s say, but at this moment I find it very useful, as it allows me to improves some reports and Queries so I can clearly see the team a work Item belongs to, without any trick to truncate the area path or something to make the information easy to filter and more readable, specially in reports.

If you are going to need this or you will follow this article, please, test it thoroughly before going live, customizations in Work Items are always tricky, and specially in this level in which we are modifying the default behavior of TFS.

Also I tested it in a TFS “15” preview environment, and it also worked successfully as expected, so going forward to next version of TFS is expected to work.

Code Search extension for VSTS and Team Foundation Server “15”

VRecently Microsoft put as Generally Available a very interesting extension in the Visual Studio Marketplace, the Code Search extension. Install it on your VSTS is as simple as go to the previous link and click install, then select the Visual Studio Team Services account in which you want to install the extension, of course you need to be an Administrator to install it.

To install on Team Foundation Server “15”, is just as simple as install it during the installation phase of TFS.


But, what enables this extension? Once you install it, on your team projects you will have, in the menu bar, a search box in which you can select to search code:



When you select code, you will be presented some of the main options to search for code.

But there are even more options you can check in the help page.

The interesting thing of this Code Search extension, is it not only look for text inside the code files, that would be easy, it searches  across all projects or just the ones  you want.

But it also allows you to put filters like for example look only for classes named like the term you are looking for, or comments, references and a lot of more, I’m really impressed on how rich it is. Of course you can refine your queries with AND, OR, NOT terms.

Also it integrates with history, so when you find what you are looking for, you can see its history, compare with previous versions, and you can even see annotations within the code.

Just as a conclusion a pretty nice extension you can start installing and using on your VSTS to search for code, but far beyond the usual look in files functionality.

As technology it uses in the behind, if you look here you will see it uses:

  • Elasticsearch
  • Oracle Server JRE, yes for TFS you will need to install it on the server, but you can install Code Search on a separate server. Of course for VSTS you don’t need to care about this.
  • Mardowndeep.
  • Roslyn (hype increasing on this one)

And about languages it supports, currently it supports C#, C++, C, VB.NET, and recently they added support for Java also, and it is ok to think they will be updating the list of languages.

So go ahead, install it and try it, you can find more options and documentation here.

I’m back! Executing Entity Framework migrations from VSTS Release Management

Uff there has been a long, long time since last time I wrote here … but, several people have lately asked me about my blog, so there I go, and better than write a bla bla article about the last time and why I haven’t wrote so much, let’s get technical.

In this article I assume you have the basic knowledge of creating Team Build definitions, and Release Management definitions. I’m not covering this topics in this article, as it would make it so long to read. If you are not familiar with this, I would recommend you to read about it here

When we are deploying applications with a database, there are several ways we can do, usually we will deploy differential scripts to update the DB, or DACPAC and other technologies, but we can also use Entity Framework migrations, although I still have to think if it is the best way to do it …

Usually migrations are executed Entity Framework initializers, but if we need to execute them before deployment, so we can be sure we updated the DB even before deploy our application, there is a tool named “migrate.exe” included in the NuGet package of Entity Framework.

There is a couple of steps we need to take to be able to execute this tool from Release Manage:

  1. Build our migrations Assembly
  2. Copy the tool migrate.exe from the tools folder in the EF Nuget package folder to the same directory as the migrations assembly
  3. Execute migrations

Let’s go with the first two steps, which we will do in a Team Build definition which publishes the results, as artifacts, to the Release Management definition. The build step is easy, usually our migrations assembly will be included in the Solution we are building to deploy our application, if not, well include it in the solution or build it in a separate build step in the same build definition, no tricks in this one.

Copy the migrate.exe tool includes a couple more of steps. First I would copy the result binaries from building the migration project to a separate folder we will publish as an artifact. This is done with a Copy task in the build steps, which we will configure this way:


The parameters:

  • Source folder: we point to the binaries result of our migration assembly, notice I have oversimplified the directory, with /MigrationAssembly/ be sure to include the full path to it. And I have used a couple of variables $(build.sourcesdirectory) a system variable which points to the root of sources downloaded by the agent, and a custom variable $(buildConfiguration) which points to the current build configuration (i.e.: Debug, Release or whatever you use).
  • Contents: ** so we copy all results.
  • Target folder: I’m copying to a new folder automatically created in the artifacts staging directory, as configured with the system variable $(build.artifactstagingdirectory), you don’t need to create a complex folder structure under this one, but be sure to at least create a folder structure which allows you to separate different results and artifacts.

Next step, copy the migrate.exe file, again we use a copy task:


With the parameters:

  • Source folder: we point to NuGet packages folder, which is usually at the same level of the solution we are building, but be sure to check this correctly, probably this path is one of the trickiest paths of this configuration.
  • Contents: “migrate.exe” well, no comments …
  • Target folder: I’m copying to a the same folder we copied the results of the migration assembly in the previous step. This is very important for all of this work, so be sure to check it twice.

And the last step in the build, publish the artifacts, usually as simple as this one, which will publish all the folder structure we have in the artifacts directory to a server artifact:


Final steps will be seen like this:


Once we have done this, we can queue this build definition, and once finished, in the resulting artifacts just check you have your binaries from the assembly migration along with the migrate.exe tool in the same folder within the artifacts.

For the Release to execute the migrate.exe file it is just a simple task of execute a command line, of course one gotcha of this is to link the build definition with the Release Management definition (again, I assume you are already familiar with this).

So within the desired environment of our Release definition, we will just add a Run on agent task of type Run script, one important point, remember this tasks runs on the agent, so you need to ensure your agent can communicate with your SQL Server or SQL Azure.

We will configure this task in this way, before the deploying task for the application:


The parameters we are using:

  • Path: here we configured the path to migrate.exe within the build artifacts we are using, you can take advantage of the “…” button to look for it, again, remember: you must have linked your Release Management definition to your Build definition for this to be available.
  • Arguments: there is different arguments you can use here, even just point to a *.config file with all the values (check full documentation), in this case I just pointed to a custom variable containing the connection string (be sure to make it secret to protect it hehe), and as I pointed to a connection string, it is mandatory to configure the parameter of “Connectionprovidername”, which in my case is just SQL Server.

Some important gotchas here, be sure to test thoroughly your migrations, and be sure to enable the appropriate backups of databases for the rollback cases, this is not easy, and you have to really take care about it, so have different environments of Release Management for test all the deployments and migrations.

Once you have this, next  time you run this Build and Release definition, your database will be (hopefully if you have done it correctly) updated to last migration from Entity Framework.

And hopefully, see you later around here with more articles Smile

[TFSService] Starting to work with Team Foundation Server Service Preview

As sure many of you have already seen, in Build Windows, it has been taught the new Foundation Service Team Preview, aKa TFS in Azure.

For that you have been lucky enough to have an invitation, we will make a brief summary of where to start.

The first thing to remember is that although with some differences, amounts to a Team Foundation Server as we are used to seeing so far in its 2010 version though.

Upon receipt of the invitation and have created your account (you need an invitation and a Live ID), a URL will be: http:// [whatever]., this is the url that we use to connect to our service in the cloud, and start working, and the URL you use to connect to our TFS Service Preview

When you finish creating your account, it enters that url automatically in the administration section

Team Foundation Server Service Administration

From this screen, the first thing we do is create a Project Team to start working which, incidentally, I love the interface Metro, we’re going to see throughout the implementation of Team Foundation Server Service. To create the project simply press the Create project team.

As a Team Foundation Server today, we asked the project name you want, description, and staff, who are also new and we can choose between:

  • Microsoft Visual Studio Scrum 2.0 – Preview 1
  • Microsoft MSF for Agile Software Development 6.0 – Preview 1
  • Microsoft MSF for CMMI Process Improvement – Preview 1

Creating Team Foundation Server Service project

After creating the project, we can move to connect with our Visual Studio 2010 (or version 11 if you have already downloaded)

Before connecting to our project, we must keep in mind one thing, with Fountadion Server Service Team Preview, we will use Live ID account to connect, something that is not ready Visual Studio 2010, so we have to download additional software.

This software will be found in our Service Management Service Team Foundation Server Preview, to access, if you have closed the web, we enter http:// [whatever]., and click on the link above to Administration right.

In the third option we see the link to download the software you need, just simple click, and download for Visual Studio 2010, will need Service Pack 1 for Visual Studio 2010 and the hotfix KB2581206.

Once downloaded and installed, we opened our Visual Studio 2010, the connection procedure is always the same (menu option Connect to Team Foundation Server Team …).

Adding the Team Foundation Server Service Server Preview to those available, you have to put [whatever] and take care selecting SSL connection, so the resulting URL is: https://[whatever]

Connection to Team Foundation Server Service

By connecting what is going to ask? for an account with Live ID that has permissions on this project in Team Foundation Server to start working.

Login Team Foundation Server Service Preview

Terms of connectivity and see that we have a Team Project Collection, and the project we created available on our Team Explorer to start the game working with Team Foundation Server Service Preview …

A difference you can see, and that is because it is a cloud service (and especially Preview) is that we do not have Sharepoint and Reporting, and we only have our beloved Work Items, Source Control and Team Build (and I speak of the latter later).

Team Explorer TFS Service Preview

And as you can see, our TFS is now on

And from this point, and if time and conditions permit, I hope to go away by making introductions to this new little wonder that we have available.

What do I mean with agile “multidisciplinary team”?

We return with items that I see, live and experience with agile methodologies. And now it’s up to the multidisciplinary teams, something that much has been written, and with many different visions.

If we follow the general concept, and in which many think, a multidisciplinary team is a team of generalists, which everyone knows to do any task needed to complete the sprint. This has a number of benefits that are obvious

  • Avoid bottlenecks
  • Facilitate communication of knowledge across the project team
  • We have multiple views on one point

And more benefits that we could go.

However, there are things we lose, as may be specialized knowledge to a particular topic.

Besides, it is quite difficult to find a good team of generalists in all the tasks that may arise in a sprint, remember that we will perform tasks ranging from front-ends of applications, databases, application deployments, etc. etc.

Therefore, in my view, to achieve a multidisciplinary team I rely on another approach. To me a computer so the computer I have, working as one, and you have all the knowledge needed to sprint, does not mean that everyone knows how to do everything.

Here we take advantage of special knowledge of any member of the team, it would be naive to believe a team of specialists only. In a team of specialists only shudder to think of the possible struggles of egos, and the struggles of each in his field.

Not bad to have a team of some experts in the fields we need, and people more generally. As long as they work as one, collaborate with each other and have all the ultimate goal of course sprint. And of course, all the team must have, at very least, a general knowledge about everything which is needed to accomplish the objective of the sprint, so we avoid big bottlenecks, and “islands” of knowledge.

And eye specialist when I’m not talking about people who can do only one thing, people, the more we know better, but then we have a more specific skill, as I said a friend of mine, specialization is for flies, humans we know many things.

General knowledge is very rewarding, and the more varied in theme, more enriching, but also know a lot about something and have much experience in it, allowing us to save not only familiar situations, if not deal with our guns unknown problems.

Documenting our Test Plans with Microsoft Test Manager

If you already know Microsoft Test Manager, you will know that it is a great tool to manage our plans for functional testing, however, to check the information concerning the plans for testing of a project in Team Foundation Server, we need the tool itself, connectivity to the TFS server, and go checking each of the Test Suites. This is all very well for the day to day, but there are times in which we have to share this information or make documentation of these plans (Yes, there is also documentation on agile projects).

To generate this documentation, our test plan,  and executions, in the visual Studio Gallery, we have a very useful tool: Test Scribe, which you can download it from here:

Once downloaded and installed on Microsoft Test Manager, we will have a new option in the main menu: Tools


From this section, we can make two main actions: a test plan documentation and obtain a report from an execution.

Documenting the test plan


In this option that we will do is, select a test plan for the project from Team Foundation Server to which we are connected and press the Generate button.

This leads us to a Microsoft Word document in which we have all the details of the test plan selected, this includes information such as:

  • The hierarchy of Test Suites
  • All the tests and their steps that make up the test plan
  • Settings to try

Ultimately a quite complete overview of the test plan.

Summary of implementation


With this option, select an execution of tests, either manual or automated, and will generate us a report that includes information such as:

  • Executed tests
  • A result of the tests
  • Defects found
  • Details of executions

Ultimately these reports they provide very interesting information, and what is best, in a format that podemso share and consult without having to be connected to our Team Foundation Server.

Give your feedback for next version of Visual Studio ALM

As in any agile process, the Visual Studio ALM team, prioritize the features and improvements for next versions of the products from the users, as you all know, feedback is an important part of building new versions.

And how can you give your feedback? well there is a UserVoice site they have set up, so you can give your feedback for the next version of:

– Visual Studio Ultimate

– Visual Studio Test and Lab Management

– Team Foundation Server

You can access it here:

Creating Work Items “tickets” (i.e.: for Call Centers) without needing Client Access License for TFS

Hi all, recently I came over a consult of a friend, on a situation he wanted to solve in his company. Basically was that they had a call center, external to them, those who wanted to give access to the Team foundation Server, but only to register and keep track of the Work Items created by the users of the call center (each user their own nothing else).

Posed me questions about, whether to publish Sharepoint portal, digital licensing, etc.

The thing is relatively simple, and we will support in two things, the publication of the website (not the Sharepoint) of Team Foundation Server, that has a url such as http://TFSSERVER:8080/tfs, and an exception in the licensing of TFS, which allowseWe have users, who can create Work Items, and keep track of those (only) Work Items created by them, without having to leave. This exception, from TFS 2010, applied both to internal users and external to the organization.

But we are going step by step, the first thing is to publish the website of TFS, as many already know, TFS is installed in IIS as a web site, Team Foundation Server name, so first thing, and I am not going to explain here, it is to publish this web site, to make it accessible from outside, either HTTP or HTTPS (the most recommended).

The next step is, in the TFS server using the Management Console, (start | Programs | Microsoft Team Foundation Server 2010 |Team Foundation Administration Console), in the Application Tier section, have a link to change the URL:


When you click that link, on the next screen, you will ask the Notification URL and the URL Server, just change the notifications, so that when issuing notifications by email for example, the links to Work Items, etc. point to the external Url. The next step is to add the users you want to have this feature, the Group of Team Foundation Server Work Item Only View Users, do this also from the management console, using the link Group Membership:


On the next screen shows all the global groups in Team Foundation Server, we select the Work Item Only View Users, and click on Properties, select on the next screen Windows user or group:


Already we can, with the Add… button Add call center users, or those who wish, also, from Visual Studio 2010, in the properties of the Team Project that we want to give access, we also have to add these users to the Group of Contributors, so they can connect with the Team Project.

When these users from accessing, you will see the web portal of only management of Work Items, which can only see their own work item:



Several reminders, to do all this, you need to be administrator of TFS, and connect remote TFS server desktop, that the management console can only be used in local.

And, of course, if users have access to source code, reports, documentation, or any other type of information to TFS, this not you worth, because they need a Client Access License (CAL) of TFS 2010.

Installing TFS 2010 and Visual Studio 2010 SP1 on Lab Management environments

As I am sure that almost everyone will remember, recently announced that Service Pack 1 for both Visual Studio 2010, and for Team Foundation Server 2010.

And one of the questions I have received lately, it’s "ok, but I have ridden Management Lab, with several virtual environments, what and where I have to install each service pack (TFS and VS)?"

The answer is simple, in part, so let it.

Team Foundation Server and Team Build 2010

The easy part, is the Team Foundation Server itself where, if we do not have Visual Studio installed on the same server, we only need SP1 for Team Foundation Server. And if we have Visual Studio 2010 also installed, you need the Visual Studio SP1 as well.

This also apply to our servers with Team Build 2010.

Test controller 2010

In our Test Controller 2010, install the Visual Studio 2010 SP1 only (siemppre and when we do not have more components of TFS).

Virtual Environments

This is where we have more work to do, because, depending on the capabilities that we have assigned to our surroundings we have to install either (or both) SP1.

Let’s first recall the capabilities we can allocate our virtual environments:

  1. Ability to execute automated tests through a Test Agent 2010 and Lab Agent.
  2. Ability to execute workflows, to deploy the application using Team Build 2010 and Lab Agent.
  3. Network isolation, to create duplicates and isolated environments at the network level. With Lab Agent.

This should already be a little clearer, so let’s see the three cases:

  1. We just need the Visual Studio 2010 SP1, as it is all part patched client.
  2. We need the Visual Studio 2010 SP1 to patch the Lab Agent, and SP1 of Team Foundation Server 2010 to patch the components of Team Build.
  3. We just need the Visual Studio 2010 SP1 to patch the Lab Agent.

And that’s it, now, encouragement, and to update our environments.