Planet SCM

If you haven’t done so already, take a look at the VSTS Beta 2 Extensibility Kit.  You’ll need to register as a VSIP developer, which is free and totally worth it because the kit contains a bunch of goodies.  It has everything from Team Foundation Server overview slides to documentation on various components of the system to samples on customizing check in process templates and programming against our core services.  This is a great resource for those who want to customize or extend TFS.  It’s also a great source of general information about the architecture and components of the system.

If you have already downloaded the kit, check it out again because we updated some of our content this Monday, May 23.  The kit now includes these additional samples.

• A test tool extensibility sample on creating custom test types (Test Tool Extensibility\Extensibility Example.zip)
• A sample application that allows you to monitor a set of work items in real time for changes (Work Item Tracking\QueryMonitor.zip)
• A sample command line based interface for work items tracking that shows you how to leverage shared controls (Work Item Tracking\WIBrowser.zip)

Enjoy,

Ling Bao

Visual Studio Team Foundation Server

A common customization request is the need to change the list values populated in the Assigned To field on a work item.  By default, this field shows all users known to TFS (members of the TFS Everyone group).

What if you want to assign work items to groups or special values that don’t correspond to a user or group?  Well, the Assigned To field is just like any other field and you can fully customize its list values.

Here’s what you do.  Export the work item type from your project (see this post for instructions on importing and exporting types).  If you want to assign work items to groups, replace the definition of Assigned To with the following XML.  This expands all users and groups defined in the project contributors group in the Assigned To pick list.

<FIELD name="Assigned To" refname="System.AssignedTo" type="String">
<ALLOWEDVALUES expanditems="true">
      <LISTITEM value = "[Project]\Contributors" />
</ALLOWEDVALUES>
</FIELD>

Note how the list shows the Contributor group, as well as the child groups such as Developers and users in those groups.

To assign work items to special string values, just add them as list items.  The XML below allows work items to be assigned to the triage team.

<FIELD name="Assigned To" refname="System.AssignedTo" type="String">
<ALLOWEDVALUES expanditems="true">
      <LISTITEM value = "[Project]\Contributors" />
      <LISTITEM value = "Triage" />
</ALLOWEDVALUES>
</FIELD>

Until next time,

Ling Bao

Visual Studio Team Foundation Server

If you’ve already played with work item tracking in Visual Studio Team System, then you should be familiar with the notion of work item types.  For example, there are four types (Scenario, Bug, Task, and Quality of Service Requirement) in the MSF Agile methodology where each type allows users to track a different kind of work item.

Of course, you organization may have different workflow or different types of work items to track.  To accommodate this variation, Team Foundation allows you to customize work item types to your content.  You can add fields, rename fields, restrict the list of allowed value for fields, change the states and supported state transitions, make fields required or read-only, make one field dependent on another, automatically populate field values, re-arrange the appearance of information on the form, and much, much more!  You can also start fresh and build a work item type from the ground up.

How do you get started?  There are two ways.

1. Edit work item types in process templates and create new team projects using the updated template
2. Edit work item types in existing team projects directly

In each case, you edit XML definition files to specify the behavior of the work item type.  

Process Templates for New Team Projects

When you edit work item types in a process template, every new team project you create with that template will have the updated work item type.  Here’s how to do this.

1. Ensure that you have “Edit domain-level information” permissions on the Team Foundation Server.  This is administered via Team Explorer by right clicking the server icon and selecting Team Foundation Server Settings->Permissions.
2. Follow the instructions in Amy’s “Customizing Process Templates” post to export a process template.
3. Open the exported folder and go to the sub-folder where work item type definitions are stored (“MSF Agile\Currituck\TypeDefinitions” for MSF Agile in the December CTP).
4. Open the XML file for the work item type that you want to edit in your favorite XML editor.
5. Start editing away and make your customizations.  For reference information on the definition language, check out “Authoring Work Item Types Using the December CTP.doc” in the “Work Item Type” folder of the December CTP Extensibility Kit.
6. Save your changes and import the process template back onto the server by following Amy’s “Customizing Process Templates” instructions.
7. Create a new project with the template and start using your customized work item type.

Work Item Types on Existing Team Projects

Once a team project is created, the only way to edit work item types in that project is to export the type directly from the project, edit it, and re-import it.  These changes are scoped to the team project and won’t alter process templates or work item types in other team projects.  To edit existing work item types, you must use an administrative utility to export and import the XML from the project.  Step-by-step instructions are provided in “Authoring Work Item Types Lab.doc” in the “Work Item Type” folder of the December CTP Extensibility Kit.  Note that for December CTP and Beta 2, you will need to be a member of the Project or Namespace Administrator group in order to import work item types.  For the final release, we are planning to create a permission for administering work item types that can be granted to other non-admin groups.

Have fun customizing your work item types!  Also, keep your eyes peeled for an updated Extensibility Kit containing the latest materials on work item type customization when Beta 2 comes out.

Ling Bao

Program Manager

Visual Studio Team Foundation

As promised, I (Amy Hagstrom, VSTF Program Manager) am back this week to discuss customizing process templates.

What are process templates?

As mentioned last week, process templates are a type of blueprint for the Team Project Creation Wizard.  They provide a set of team project customizations that support the processes a team should follow.  VSTS will ship two process templates: MSF for Agile Software Development and MSF for CMMI Improvement.  Out of the box, process templates will include these elements:

·        Work Items

o       Type definitions (such as Defect, Task, and Issue) – stay tuned for a post in the next couple weeks that covers modifying Work Item type definitions in more detail

o       Queries

o       Instances – these make up a Project Roadmap (a predetermined set of tasks that must be done for every project, such as gathering requirements or writing a vision document)   

o       Mapping of Work Item fields to MS Project columns

·        SharePoint Site layout, theme, and content

o       Document Templates

o       Process Guidance

·        Version Control Settings

o       Check-in notes

o       Permissions

o       Multiple check-out

·        Reports (SQL Reporting Services)

·        Groups and Permissions

·        Iterations

Beyond this, 3^rd parties can write plug-ins for the Project Creation Wizard that could consume their own custom process templates elements. 

How are process templates customized?

1. It is best to start with an existing process template.  To do this first launch the Process Template Manager in Visual Studio by going to the Team menu > Team Foundation Server Settings > Process Template Manager.

2. Select the process template you want to base your custom process template on, and choose “Export.”  This will download the process template to a local directory you specify.  The process template is a cohesive set of folders and files.

3. To change the name and description of the process template, edit ProcessTemplate.xml:

...

<methodology>

     <metadata>

      <name>Name of my Custom Process Template</name>

      <description>Use this process template for projects that require light processes… </description>

...

4. Determine which modifications you want to make, and edit the appropriate xml files using your favorite xml editor.  In the below SCCTasks.xml I’m adding a new required check-in note called “Comments”, and making exclusive check-out required:

<?xml version="1.0" encoding="utf-8" ?>

<tasks>

    <task id="SccTask" name="Create Source Control area" plugin="Microsoft.Pcw.Scc" completionMessage="Source control area created.">

      <dependencies/>

      <taskXml>

<permission access="Read, PendChange, Checkin, Label, Lock, ReviseOther, UnlockOther, UndoOther, LabelOther, AdminProjectRights, CheckinOther" grant="allow" identity="$$PROJECTNAME$$\Project Administrators"/>

      <permission access="Read, PendChange, Checkin, Label, Lock" grant="allow" identity="$$PROJECTNAME$$\Contributor"/>

      <permission access="Read" grant="allow" identity="$$PROJECTNAME$$\Reader"/>

      <checkin_note label="Code Reviewer" required="true" order="499"/>

      <checkin_note label="Comments" required="true"/>

      <exclusive_checkout required="true"/>

      </taskXml>

      </task>

</tasks>

5. If you are including new files (like a new document or report), add those files to the appropriate place in the folder structure. 
6. To upload your customized process template, launch the Process Template Manager again and do so via the “Import” button.

Any comments or questions?

Amy Hagstrom

Program Manager

Visual Studio Team Foundation