Teams WIT Tools : Rosario

SharePoint Integration in TFS 2010 Beta1

jontsao — Mon, 01 Jun 2009 20:20:47 GMT

Last month, Brian Harry outlined some of the new features in the setup and administration experience for TFS 2010 here. This post drills into how SharePoint integration works for Beta1.

Installation

In TFS 2010, we’ve separated the installation from the configuration of TFS. The installation and configuration of SharePoint occurs during the configuration stage of TFS. This addresses a pain point we’ve heard from customers using 2008, where if for some reason, installation or configuration of SharePoint failed, the entire installation of TFS failed as well and rolled back.

When installing TFS 2010, you can choose to install:

Team Foundation Server – Choose this option if you are planning to either deploy only TFS on this box or keep SharePoint and TFS on the same box.

Extensions for SharePoint Products and Technologies – Choose this option if you have SharePoint already installed on the box and want to enable integration with TFS on another server. (Note: this option will not appear if you do not have SharePoint already installed.) This option supports both single-server and farm environments.

User Accounts/Permissions

Our SharePoint integration is much more flexible in 2010, but with this flexibility comes a bit more complexity. If you want to integrate SharePoint with TFS in 2010, then you need to create a two-way mapping: the TFS instance must know where the SharePoint instance is and vice versa. Depending on how you configure SharePoint, the same may hold true of the service accounts. That is, the TFS service account will need access to SharePoint (it must have farm administrator privileges) and the SharePoint service account will need access to TFS.

There are two main scenarios in installation:

Scenario A: as a TFS administrator, you are in charge of both TFS and SharePoint.
Scenario B: as a TFS administrator, you do not have control over SharePoint. For example, this may be the case if SharePoint is managed in a corporate farm.

Scenario A is the simpler of the two, and if you’re installing TFS and SharePoint on the same server, then your setup can become even simpler, as you’ll see below. In Scenario B, you’ll need to work together with your organization’s SharePoint administrator to integrate TFS and SharePoint. The TFS installation help file includes a useful worksheet that helps you and your SharePoint administrator collaborate on the information necessary to successfully configure TFS/SharePoint integration, including user accounts.

Configuration

Once the installation succeeds, you’ll move on to the configuration stage. Your options vary depending on whether you installed TFS or the extensions. One of the known issues discussed in the Beta1 ReadMe is a bug that occurs if you choose not to start the configuration wizard right after completing the MSI install (that is, you uncheck the “Launch Team Foundation Server Configuration Tool” option on the setup’s “Finish Page”). Buck Hodges has a great blog post here explaining the issue and how to avoid it.

Team Foundation Server
- Default Configuration
  
  This is the option you should choose if you plan on using a single server for TFS, SQL, and SharePoint. This option installs and configures Windows SharePoint Services (WSS) 3.0 for you, so if you already have SharePoint installed on the server or want to use Microsoft Office SharePoint Server (MOSS), you’ll need to run the custom configuration. Otherwise, just provide TFS with the details on the service account you want to use for SharePoint, and TFS will do all the installation and configuration for you.
- Custom Configuration
  
  This option allows you to customize various aspects of the TFS configuration. By selecting this, you can:
  - Opt out of installing/configuring SharePoint. To opt out, just uncheck the “Configure Sharepoint…” checkbox.
  - Install and configure WSS 3.0 on the server to integrate with TFS. While the Default Configuration does this for you as well, we offer this choice in custom configuration since you may wish to customize other, non-SharePoint related options. As in the Default Configuration, you’ll need to provide a service account for SharePoint.
  - Integrate TFS with an existing SharePoint site. If you fall under Scenario B described above, you’ll want to use the custom configuration to hook up TFS with SharePoint.
- Application-Tier Only
  
  This is the option you should choose if you separate your application tier from your data tier (your SQL server instance for TFS is on a different server) and you do not want to install/configure SharePoint.
- Upgrade from a previous version
  
  You can select an existing SharePoint site you want to integrate with. Note that the instruction text on the preceding page is incorrect. You cannot install SharePoint on upgrade in Beta1.
Extensions for SharePoint Products and Technologies

There’s not much to configure on this page. :) Just press “Configure” and you’re done.

TFS/SharePoint Mappings

The following diagram represents the recommended mappings when integrating with SharePoint.

TFS Instance/SharePoint Web Application

If you chose to integrate with SharePoint during configuration of TFS, this mapping is created for you. On the TFS side, you need the following information to create/edit mappings to Sharepoint Web Apps:

The service accounts used for the SharePoint Web Application
The base URL for SharePoint Web Application
The SharePoint Central Administration URL
The relative path for the Sharepoint sites for Team Projects

You can change the mappings in the SharePoint Web Applications Node of the Team Foundation Administration Console:

Recall that mappings are two-way. Thus, if you’re customizing the mappings or you’re creating a new mapping in the TFS Administration Console, you’ll need to keep the mappings from SharePoint to TFS in sync as well. If you are not the SharePoint administrator (scenario B, above), you’ll need to work together to create the mappings.

On the SharePoint server, the TFS mappings can be configured in the Extensions for SharePoint Products and Technologies node of the Team Foundation Administration Console. The following information is needed on the SharePoint side:

The TFS service account, so that this can be added to the SharePoint farm administrators group
The URL for the TFS instance
For MOSS administrators: the single sign on name

Again, if you find yourself in scenario B, the TFS installation help file for Beta1 has a handy worksheet that you and your SharePoint administrator can use to make these mappings a smooth process.

Team Project Collection/SharePoint Site Collection

In TFS 2010, we’ve introduced the concept of a Team Project Collection (TPC). Brian Harry has a great blog post that defines and describes this key concept. You can create TPCs in the Team Foundation Administration Console. If you have SharePoint integration set up and you create a TPC, TFS can create and configure a new SharePoint site collection for you that maps to the TPC (the TFS service account must be added to the SharePoint farm administrator group for this to be successful).

Note that with this integration, you get the added bonus that, if you want to backup/restore your Team Project Collections, you can also backup/restore the corresponding site collections through SharePoint’s own backup/restore mechanism. This allows you to take full advantage of our support for moving TPCs to different servers.

Team Project/SharePoint Site

As with TPCs, if you have SharePoint integration set up and you create a Team Project, TFS can create a correlating SharePoint site that serves as the new Team Project’s portal page.

If you click “Configure…”, you can choose where you want to create the new SharePoint site:

While we give you flexibility here as far as the location, we recommend that you keep the location as a subsite of the project collection to enable the backup and restore scenario we mentioned earlier.

Note that if you wish, you don’t have to create the Process Guidance. You can configure the location of the process guidance later in the Project Portal Settings. This way, if multiple projects are using the same process, you can have them share the same guidance. Instead of updating the guidance for each project, you can now update it in one place.

Finally, in keeping with our theme of added flexibility, there’s an option not to create a SharePoint site at all. You can configure where the portal is later by entering the relevant data in the Project Portal Settings dialog. The dialog allows you to choose whether you want to use a SharePoint site (where TFS can easily integrate its reports and dashboards) or a fully qualified URL of your choice. The same goes for the process guidance.

Useful links

Beta1 install help file (.chm) - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2d531219-2c39-4c69-88ef-f5ae6ac18c9f

Brian Harry: TFS 2010 Admin, Operations & Setup Improvements - http://blogs.msdn.com/bharry/archive/2009/04/30/tfs-2010-admin-operations-setup-improvements.aspx

Buck Hodges: TFS 2010 Beta 1: Don’t run initial configuration from the administration console (MMC) - http://blogs.msdn.com/buckh/archive/2009/05/18/tfs-2010-beta-1-don-t-run-initial-configuration-from-the-administration-console-mmc.aspx

What improvements to subscriptions and notifications would you like to see?

sbhatia — Wed, 30 Jan 2008 08:38:00 GMT

I'm posting this on behalf of Matthew Moloney -- a PM intern who has joined us from Australia!

He's got a query on what sort of improvements you'd like to see in the subscriptions & notifications space in a future release.

------

G'day everyone,

I'm looking for feedback on a design for a subscription and notification interface that will allow users to specify which events they would like to be notified on. I would also like to get a few ideas on what would be the most common types of notifications that a users such as you would like to subscribe to.

Some ideas have been:

· "I would like to receive an email when any of my Bugs have been updated"

· "I would like to know when I have been assigned a new work item"

· "I would like to be notified when a work item that was previously assigned to me has been assigned to someone else"

By collating such request into a set of common requests we can try to optimize a user interface.

The idea is analogous to the Outlook rules and alerts wizard. The intent is to have two different approaches. A wizard that will be able to facilitate the event subscriptions for 80% the most common cases, and a Query Builder driven approach that will handle the remaining 20%.

The most important input I am looking for is your answer to the following question; if an ideal subscription and notification infrastructure existed what events would you subscribe to and how would you like to receive those events? In order to quantify each of the answers please give an indication on the subscriptions importance (integral, very important, nice to have) and on the frequency of occurrence (all the time, regularly, occasionally).

Some things to consider:

If you could only subscribe to changes in queries as opposed to individual work items could that be enough?

For subscribing to a change in a query how would we define 'a change in the query'?

· When work items within the query has changed in a certain way; or

· A new work item enters the query results or an old item leaves the query results

And, what kinds of notification endpoints are desired?

· Email

· Instant Messaging

· RSS

· Newspaper (A webpage collating events)

Thanks for your time,

Matthew Moloney

New permissions on work item types?

sbhatia — Wed, 30 Jan 2008 07:17:00 GMT

Folks,

I recently sent out a request to the VSTS Customer Council and the MVPs asking them if they had thoughts on important new permissions to add to work item types in a future release.

Note that we’ve already enabled the following scenarios:
• Hide work items under a particular area node from a group of users (in TFS 2005)
• Set work items as read only under a particular area node for a group of users (in TFS 2005)
• Allow TFS Server admins & project admins to destroy work items as well as destroy work item types (in TFS 2008 + Power Tool)
• Allow TFS Server admins & project admins to rename work item types (slated for “Rosario”)

The high-level results on the priorities of potential new permissions on work item types were:

As a result of the feedback, we are unlikely to make an investment in new permissions for work item types and a model around that. However, we are looking at a creative workaround/solution for the top ranked request ("Allow/Deny a user to 'Contribute' on work items of a particular type) involving work item rules.

My questions for you:

Do you agree with this prioritization? Are there scenarios that are more important/less important to you?
Have you encountered any really painful scenarios in and around this area that we should really look at?

Thanks,

-Siddharth

Rosario: What is the “Name” attribute for on Links Control XML

Gregg Boer — Tue, 21 Aug 2007 00:34:00 GMT

Last post, I talked about how to filter on link types. Here’s an example:

</LinksControlOptions>

</Control>

Some of you may have wondered want the “Name” attribute is for?

Well, it does have a purpose. :-)

The TFS Client uses this name to store the column widths for the links control. If you, the user, would adjust a column width on a links control, the TFS Client will remember that width by storing it in the client machine’s registry. It uses the Name value to retrieve that information. This allows a form designer to move the links controls to a different location on the form, and as long as the Name value is still the same, the TFS Client retains the user-defined column widths.

Therefore, changing the value of the Name attribute will result in all of the users who have set the column widths just the way they like them to lose them. Not the end of the world, but something to be aware of.

Other than the fact that the name must be unique for a work item type, it is arbitrary and set by you. So you decide what you want it named.

Rosario: Filtering link types on a work item form

Gregg Boer — Mon, 20 Aug 2007 23:57:00 GMT

In Whidbey, and Orcas, the work item links control that displayed the links always showed all the links. For Rosario, we made a design decision based on the fact that whoever is designing a work item form, may want to display certain link types separately from other link types.

For example, let's say you have a tab on the work item form which manages your dependent features. It would make sense that the links control on that tab only display links to dependent features.

This is where the new filtering functionality with the links control comes in.

In the work item type XML in Whidbey/Orcas, this is what you did when you wanted to display a links control:

With Rosario, we’ve add the LinksControlOptions section to allow you to filter what link types to include.

The simple example would render a links control that includes all work item links (Related, Parent/Child), and exclude any non-work item links (ChangeSets, Hyperlinks, Test Results):

</LinksControlOptions>

</Control>

The following example would render a links control that displays only Requirement and Hierarchy links.

</WorkItemLinkFilters>

</LinksControlOptions>

</Control>

The following example would render a links control that displays all work item links except Requirement and Hierarchy links.

</WorkItemLinkFilters>

</LinksControlOptions>

</Control>

The following example would render a links control that displays only Change Set links.

</ExternalLinkFilters>

</LinksControlOptions>

</Control>

That should give you a pretty good idea of what can be done. Any questions? Feedback?

Rosario - Customing Link Types Primer

Gregg Boer — Fri, 17 Aug 2007 19:17:00 GMT

With Rosario, you can define multiple link types. This allows for you to customize link types to match your processes. This blog post is a primer in how to do that.

Quick-start guide on creating a new link type:

Here's how to create a new link type:

From the command shell, go to “Program Files\Microsoft Visual Studio 9.0\Common7\IDE”
Run "witadmin.exe exportlinktype /s ServerName /n System.LinkTypes.Dependency /f mylinktype.xml”
View the mylinktype.xml file that was created. It should look like this:

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

<LinkTypes>

<LinkType ReferenceName="System.LinkTypes.Dependency" ForwardName="Successor" ReverseName="Predecessor" Topology="Dependency" />

</LinkTypes>

Edit the mylinktype.xml file to look like this.

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyLink" ForwardName="My Successor" ReverseName="My Predecessor" Topology="Dependency" />

</LinkTypes>

NOTE: It is important to change the namespace from “System.” To “MyLinks.” (or some other name), because “System.” Is a protected namespace.

Run “witadmin.exe importlinktype /s ServerName /f mylinktype.xml
Go to your Team Explorer and select “Refresh Cache”, or close and reopen your Visual Studio.

The new link item type should now be available to use from your forms.

What is that "topology" field for?

Now, what is that “topology” field in the definition XML. Topology assigns a set of rules that are enforced for that link type. There are four topologies to select from:

Network

Link types of this topology have essentially no rules and no directionality. You can have circular relationships, and the link looks the same from both sides.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyRelated" ForwardName="My Related" ReverseName="My Related" Topology="Network" />

</LinkTypes>

Directed Network

Link types of this topology are like Network links, except there is directionality. You can specify a name that appears at each end of the link. In other words, the link looks differently depending from which side you view it.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyDependent" ForwardName="My Dependent" ReverseName="My Provider" Topology="DirectedNetwork" />

</LinkTypes>

Dependency

Link types of this topology are like Directed Network links in that they have directionality, but an additional constraint to prevent circular relationships.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyPred" ForwardName="My Successor" ReverseName="My Predecessor" Topology="Dependency" />

</LinkTypes>

Tree

Link types of this topology are essentially trees, it enforces a one-to-many relationship and doesn’t allow circularity.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyTree" ForwardName="My Child" ReverseName="My Parent" Topology="Tree" />

</LinkTypes>

There you have it. Creating link types in a 343 words. Let us know how it goes.

Rosario: Managing hierarchies in Microsoft Excel

Yogita Manghnani — Fri, 10 Aug 2007 22:04:00 GMT

As a follow up to Gregg's post on querying on links and creating tree queries, I'd like to introduce you to managing work item hierarchies in Microsoft Excel.

Creating work item hierarchy

There are a few ways you can get started with creating hierarchies in Excel:

Create a tree query in Team explorer and export it to Excel by right clicking on the query and choosing "Open in Microsoft Excel".
Alternately, create a query bound list in Excel and bind it to a tree query. The dropdown that lists the queries now has icons to easily distinguish between tree queries and non-tree queries.
Export one or more items from Team explorer query results view to Excel and then click on either "Add tree level" or "Add child" button in the toolbar. This will automatically bring in all the child work items for items in the list.
Alternately, create an empty ID bound list in Excel and then click on either the "Add tree level" or "Add child" button in the toolbar. Then import one or more work items into the list using the Get work items dialog.This will automatically bring in the selected work items and all their child work items into the list.

You will notice multiple Title columns in the list, one for each level in the hierarchy of work items.

Extending the hierarchy

"Add tree level" extends the tree by adding a new Title column. For ex. you have a tree of features and tasks, and want to break down the tasks further into sub-tasks.
"Add child" inserts a new row in the list. For ex. you want to add a new task to a feature in the list. You can also choose to manually insert additional rows into the list. The benefit of using the Add child button is that it will also add a new Title column if necessary.

Updating hierarchy links

To add, remove or update hierarchy links, you do not have to use the Links and Attachments dialog for each work item. This can be easily accomplished by moving the title values from one Title column to another. More over, it allows you to create and edit links in bulk.

To make a work item a child of its sibling (demote), cut and paste its title into the Title column to the right.
To make a child work item a sibling of its parent (promote), cut and paste its title into the Title column to the left.
To delete a link between 2 work items, either cut and paste the child work item's title to the very first Title column or delete the entire row from the list and publish.

Let us know what you think about this functionality and how you plan to use it.

Rosario: Querying on Links

Gregg Boer — Fri, 03 Aug 2007 20:31:00 GMT

The enhanced query builder in Rosario offers the ability to query on links. This gives you the ability to ask the system questions like:

· Give me all the Scenarios and any Bugs that might be linked to them.

· Give me only the Scenarios that have Bugs linked to them

· Give me only the Scenarios that don’t have any Bugs linked to them

And finally,

· Give me a Scenario, and recursively give me the tree of child Tasks below them.

The query builder allows all of these. To query on links, you first select the “Query on links” checkbox from the query builder view.

You will now see three panes

· The top one (the one you’ve always worked with) allows you to specify the main list work items. In the examples above, it relates to “Give me the Scenarios…”

· The middle one refers to what type of links you want to query on. Since work items can be linked together via different link types (Parent/Child, Related, Predecessor/Successor), you can filter on what type of link relationship to include. Default is “[Any]”, or All link types.

· The bottom pane refers to the filter on the linked items. In the above examples, it would relate to the “Bugs” or “Tasks” part of the scenario.

The query type defines how you want the query to return the information. You have the following choices:

· “All” – Return all items matching the main query (top query pane), and all linked items matching the bottom pane.
Example: Give me all the Scenarios and any Bugs that might be linked to them.

· “Must have” – Return only the items matching the main query that have links to items matching the bottom query.
Example: Give me only the Scenarios that have Bugs linked to them

· “Must not have” – Return only items matching the main query that DO NOT have links to items matching the bottom query
Example: Give me only the Scenarios that don’t have any Bugs linked to them

· “Tree” – Recursively return all children of the items in the main query.
Example: Give me a Scenario, and recursively give me the tree of child Tasks below them

Hope this helps to make sense of this. Let us know what you think!

What’s new in work item tracking in Microsoft Visual Studio Team System code name “Rosario”

Gregg Boer — Fri, 03 Aug 2007 20:02:00 GMT

What’s new in work item tracking in Microsoft^®Visual Studio^®Team System code name “Rosario”

Traceability is a big push with Rosario. To that end, we have improved the linking functionality is work item tracking, in Rosario.

Before Rosario, there was only one type of link between work items: “Related”. With Rosario, you can define as many different link types as you want. Each link type can be named, and can be defined to have certain rules that are enforced for you by TFS.

OK, what does this really mean?

Well, it opens the door to implement a real traceability solution in TFS. You can now create trace relationships between work items such as

· Parent / Child

· Predecessor / Successor – (Any ideas on how this might be useful with MS Project integration J)

· Fulfills / Fullfilled By – For relating Requirements to Features. Requirements are fulfilled by Features. Features fulfill requirements.

· Depends On / Required By – For relating Features to each on to define feature dependencies. Feature A depends on Feature B. Feature B is required by Feature A.

Since you can define new link types, you can customize your system to implement the process that you use.

What link types do you think you would create?