TFS Task Group Admin Management - tfs

I know in TFS 2018, the ability to import/export task groups was made available to share task groups across different projects and collections. As a TFS admin trying to give a task group to all collections/projects, is there a way to create a task group that all collections/projects can use and I can update in one place and it be reflected everywhere?
I think the import/export is a step in the right direction, but would require me to maintain the task group in each project separately.
Thanks!

Task groups are stored at project level, and are not accessible outside the project scope. You would either import the task group manually on UI, or use REST api to program your own solution to import to other team projects.
The rest api is as below:
Get the task group from team project A
-
Get http://TFS2018:8080/tfs/DefaultCollection/teamprojectA/_apis/distributedtask/taskgroups/{taskGroupId}?expanded=true
The response looks like below:
{
"count": 1,
"value": [
{
"tasks": [......]
}
]
}
Import the task group to team Project B, the body part captures the "tasks" information from the response of above api
-
Post http://TFS2018:8080/tfs/DefaultCollection/teamprojectB/_apis/distributedtask/taskgroups?api-version=4.0-preview.1
Content-Type:application/json
{
"tasks": [......]
}

Task groups are configured per team project.
What you could do is to choose one as your template and then replicate it manually with export/import.

Related

Deploy OpenAPI to localhost

My organization has a lot of APIs for different projects. I need an OpenAPI implementation that allows me to create a standalone portal that contains all these APIs (more like a repository) for all our products.
Is there an OpenAPI that supports this?
Another option would be: to be able to merge several instances to a single OpenAPI instance.
There are several ways to implement API catalogs.
Swagger UI (open-source)
Swagger UI 3.0.19+ can display multiple API definitions using the url parameter.
// index.html
const ui = SwaggerUIBundle({
dom_id: '#swagger-ui',
urls: [
{name: "petstore", url: "http://petstore.swagger.io/v2/swagger.json"},
{name: "instagram", url: "https://api.apis.guru/v2/specs/instagram.com/1.0.0/swagger.yaml"}
],
"urls.primaryName": "petstore", // default spec
...
Result:
Since Swagger UI is open source, you can customize its layout and look&feel as your needs dictate.
SwaggerHub (commercial)
SwaggerHub provides API catalog hosting for teams & organizations, either in the cloud or on premises. SwaggerHub also supports API design, collaboration, code generation and workflow integrations among other things.
Disclosure: I work for the company that makes SwaggerHub.
To do that, a great solution is to use SwaggerHub as indicated. However, this tool is not free for private API.
I had the same need, so, to help community in OpenAPI design, I wrote a new tool named "OpenAPI Dev Tool" (in github).
With OpenAPI Dev Tool, we can deploy several documentations (for several use contexts) for Swagger UI / Redoc with hot reload feature, like an SwaggerHub.
It is really easy to use.
Each API is indicated in a configuration file :
{
"folder": "./specs", // Root folder where the specifications are stored
"specs": [ // Array of specifications (several specifications can be exposed)
{ // First specification file
"file": "/petstore.yaml", // Relative path of the specification main file (from "folder" parameter). It has to be an OpenAPI file in YAML or JSON.
"context": { // Object used for template generation (see Template usage chapter below)
...
}
},
{ // Second specification file
"file": "/petstore2.yaml"
...
}
]
}
Then, you can serve the whole API just by hitting npx openapi-dev-tool serve
Open your browser with http://localhost:3000 et voilĂ  :)

How do you change the drop folder for historical builds in TFS 2010

Our server that has been used for our build drop locations is being retired. I know how to change the current build definition to use the new server, but how do you change the historical records for builds that have already completed? I want to be able to open past builds and click on 'Open Drop Folder' and be taken to the new server. We will manually copy the old builds to the new server.
The following sample seemed to work:
using System;
using System.Collections.Generic;
using Microsoft.TeamFoundation.Build.Client;
using Microsoft.TeamFoundation.Client;
namespace ChangeDropLocation
{
class Program
{
static void Main()
{
TfsTeamProjectCollection teamProjectCollection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri("http://MyServer:8080/tfs/Collection"));
var buildService = (IBuildServer)teamProjectCollection.GetService(typeof(IBuildServer));
IBuildDetail buildDetail = buildService.GetBuild(new Uri("vstfs:///Build/Build/1506"));
buildDetail.DropLocation ="\\somewhere";
var buildDetails = new List<IBuildDetail>();
buildDetails.Add(buildDetail);
buildService.SaveBuilds(buildDetails.ToArray());
}
}
}
One thing that you should take into account is that you 'll probably be lacking the privilege to update build information. In my first attempt, although I am a Project admin, I got the following:
TF215106: Access denied. DOMAIN\username needs Update build
information permissions for build definition myBuildDefinition in team
project MyTeamProject to perform the action. For more information,
contact the Team Foundation Server administrator.
In order to overcome this, set the right by right-clicking in TeamExplorer "Builds" & then select "Security...".
I don't know of any tool to do this. Maybe there is a TFS powershell command, but short of that I think you could - AFTER TAKING PROPER PRECAUTIONS OF COURSE - update the SQL Db directly.
The mapping to the drop location is stored in the collection SQL Db in tbl_Build.
select [DropLocation],[DropLocationRoot],[LogLocation] from [tbl_Build]
I'm not sure if there are any implications on the warehouse though. Might want to check on that first.
I believe Microsoft generally recommends against manipulating SQL directly for stuff like this. You could use the TFS API instead which would be a relatively safer approach.

How to "order" tasks in TFS

I'm relatively new to TFS and I've been trying to figure out how to order tasks as follows.
Task 1
Task 2 (requires that Task 1 be completed first)
Task 3 (requires that Task 1 and Task 2 be completed first)
etc
Is there a way to do this? We are using TFS 2010.
Well.. I found it.
You can specify that a task is a "Predecessor" or a "Successor" to another task, or multiple tasks when you define the link between the two.
There is some basic info about it at this location: http://msdn.microsoft.com/en-us/gg465266
It looks like the tasks are ordered by Backlog Priority then ID. By default the backlog priority is blank and is not available to be updated in the UI for tasks.
You can add the field into the UI by modifying the process template.
I found the easiest way to manage these is to create a view that includes the backlog priority, open it in excel and manage them from there.
As the OP has stated, you can use the "Predecessor" or "Successor" links. However, if you're just looking to set the order of the tasks and keep them as a "Child" of the parent User Story:
Run the query in TFS > Open in Microsoft Office > Open in Excel
In Excel, show the "Stack Rank" column. The user story will have a stack rank value, but the tasks will not.
Set the stack rank for the tasks for each user story.
Click the publish button in Excel.
Re-run the query in TFS and the tasks should now be ordered (assuming you have ordered by stack rank).

Tfs custom work item value migration

I have a task to create reports about various work items from a Team Foundation Server 2010 instance. They are looking for more information than the query tools seem to expose which is why I am not using the OOB reporting capabilities. The documentation on creating custom reports against TFS identify the Tfs_Analysis cube and the Tfs_Warehouse database as the intended sources for reporting.
They have created a custom work item, "Deployment Requests", to track requests for code migrations. This work item has custom urgency levels (critical, medium, low).
According to Manually Process the Data Warehouse and Analysis Services Cube for Team Foundation Server, every two minutes my ODS (Tfs_DefaultCollection) should sync with the Tfs_Warehouse and every 2 hours it hits the Tfs_Analysis cube. The basic work items correctly show up in my Tfs_Warehouse except not all of the data makes it over, in particular, the urgency isn't getting migrated.
As a concrete example, work item 19301 was a deployment request. This is what they can see using the native query tool from the web front-end.
I can find it in the Tfs_DefaultCollection and the "Urgency" is mapped to Fld10176.
SELECT
Fld10176 AS Urgency
, *
FROM Tfs_DefaultCollection.dbo.WorkItemsAre
WHERE ID = 19301
trimmed results...
Urgency Not A Field Changed Date
1 - Critical - (Right Away) 58 2011-09-07 15:52:29.613
If I query the warehouse, I see the deployment request and the "standard" data (people, time, area, etc)
SELECT
DWI.System_WorkItemType
, DWI.Microsoft_VSTS_Common_Priority
, DWI.Microsoft_VSTS_Common_Severity
, *
FROM
Tfw_Warehouse.dbo.DimWorkItem DWI
WHERE
DWI.System_Id = 19301
Trimmed results
System_WorkItemType Microsoft_VSTS_Common_Priority Microsoft_VSTS_Common_Severity
Deployment Request NULL NULL
I am not the TFS admin (first exposure to TFS is at this new gig) and thus far, they've been rather ...unhelpful.
Is there be a way to map that custom field over to an existing field in the Tfs_Warehouse? (Backfilling legacy values would be great but fixing current/future is all I need)
Is there a different approach I should be using?
Did you mark the field as reportable? See http://msdn.microsoft.com/en-us/library/ee921481.aspx for more information about this topic.
Based on Ewald Hofman's link, I ran
C:\Program Files\Microsoft Visual Studio 10.0\VC>witadmin listfields /collection:http://SomeServer/tfs > \tmp\witadmin.txt
and discovered a host of things not configured
Reportable As: None
At this point, I punted the ticket to the TFS admins and indicated they needed to fix things. In particular, examine these two fields
Field: Application.Changes
Name: ApplicationChanges
Type: PlainText
Use: Project1, Project2
Indexed: False
Reportable As: None
or
Field: Microsoft.VSTS.Common.ApplicationChanges
Name: Application Changes
Type: Html
Use: Project1, Project2
Indexed: False
Reportable As: None
It will be a while before the TFS Admins do anything but I'm happy to accept Edwald's answer.

How to determine used process template in Team Foundation Server after creation of team project

I'm looking for a way to determine what process template was used for a team project after it has been created. I can now only guess by looking at the work item types. I could not find any option in Visual Studio to retrieve this information. I need to know what processs template was used for team projects not created by myself.
If you check your work item type:
Scrum = Product Backlog Item
Agile = User Story
CMMI = Requirement
For TFS 2010 & TFS 2012, you can follow below process to determine which process template a team project used:
Go to Team Explorer;
Open Documents folder;
Process Guidance;
Open ProcessGuidance.html, this will open specific Process Template documenation that your team project base on.
Refer to thread
There is no way to tell, in general.
If you create (or edit) a process template, you can put an identifier into a property then you will be able to track which projects have your template(s)
To do this:
Edit Classification\Classification.xml
add a node:
tasks/task/taskXml/properties/property
like this:
<property name="templateName" value="myTemplate_1.0.1" />
Once you have projects created with this template, in the object model you will be able to pull this info from a project:
TfsTeamProjectCollection c = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(myuri);
WorkItemStore wis = tpc.GetService();
ICommonStructureService ICss = tpc.GetService();
foreach (Project p in wis.Projects)
{
string ProjectName = string.Empty;
string ProjectState = String.Empty;
int templateId = 0;
ProjectProperty[] ProjectProperties = null;
ICss.GetProjectProperties(p.Uri.ToString(), out ProjectName, out ProjectState, out templateId, out ProjectProperties);
Console.WriteLine("Project: {0}\tTemplate: {1}", ProjectName, ProjectProperties.Where(n => n.Name == "templateName").FirstOrDefault().Value);
}
templateId is always -1 so dont think that will help you.
Also - If you have the rights to, I recommend adding this property into all the templates (even the default templates) in your collection, so that you will be able to track the templates of all future projects. Don't know why they didn't put it in the default templates. (if enough people complain maybe they will)
I found another workaround: in SharePoint Central Administration you can see in the Site Collection list a comment that described the process template that was used. I was actually looking for a way to programatically retrieve it via the TFS API, but could not find it.
Using witadmin, you can list the work item types in the project. The /collection parameter is the TPC url and the /p parameter is the project name. Here is an example (below). If you know the name of a work item type that is specific to a process template, then you know which process template is being used.
Output of command console from my test TFS:
D:\Program Files\Microsoft Team Foundation Server 2010\Tools>witadmin listwitd /collection:http://suluserver:8080/tfs/De
faultCollection /p:"First Team Project"
Bug
Shared Steps
Task
Test Case
User Story
Issue
Risk
User Scenario
Risk-Issue
For visual studio online, go to your collection profile page. You can see all the projects inside your collection including the process template information.
The URL format to your collection page should be:
https://[accountname].visualstudio.com/[collectionname]/_admin
This is definitely late but here's a couple different resources I found while searching:
If you have access to the TFS database: Determine Process Template SQL
Open source WinForms application: https://github.com/renevanosnabrugge/TFS-ProcessTemplateVersionCheck
I don't know a fail proof way to find this out.
I would recommend the following: There is a exe called witexport.exe that can export the xml of a work item. You can then look through the xml to see what kind of template was used. (ie if the conchango template is used you will see references to it.)
To run it fire up the VS Command line prompt (in the start menu). Here is an example run:
witexport /f "C:\Type.xml" /t "http:\MyServer:8080" /p MyProject /n "Sprint BackLog Item"

Resources