I have a requirement and I am not able to figure out the solution. Any kind of help is appreciated.
We have customised the process model.
Issue.
I have FactTable say Release, Release has Project, projects would internally have different states, development-production-QA. what i need to do is generate a query that would get me all the defects that are open for a particular project, for a selected stage and selected release.
Is this possible?
Can we write sub query in TFS?
I would appreciate any kind of help provided.
If I had to do it, I would make itrations for: development, production, and QA.
Then iterations shows everywhere from the simple query to the TFS Warehouse!
You can consider Release as team Project Collection, then Project as team Project. For development-production-QA stages you can either use Area or create a custom work item field "Stage" with reportable attribute as "dimension".
Now you can use wither TFS_Analysis i.e. Cube or TFS_Warehouse to get your data.
Related
I have a request to add a new field to a work item and we are using TFS 2017. My organization has done this before in previous versions of TFS. However, I remember customizing any process template to add new fields causes headaches when upgrading to the next version of TFS.
My question is if this is still a concern? If so, is there a work-around for this issue?
Thanks!
Tim
Basically, you would have the same procedure if you want to upgrade a on-premises TFS with customizations.
So, before you customize, you should understand which customizations support an easy update path and which do not.
Recommended practices:
Identify the best options for customizing WITs that support your
tracking requirements. When you change objects that track work items,
you should identify how these changes will affect existing and future
team projects.
Put processes and all XML definition files under version control. Do
not deploy objects that you define but have not stored in a
repository.
Test your customized objects just as you would test your software.
Minimize the number of custom fields that you introduce. Minimize the
number of fields that you make reportable.
Please refer to the link below for more information:
https://learn.microsoft.com/en-us/vsts/work/customize/on-premises-xml-process-model#before-you-customize
I have a TFS 2015 installation where we have a rather big number of projects. Currently there are old projects, that aren't used anymore but need to stay available as an archive (read only).
I'd like to make a workspace or something in TFS so that these projects normally don't come up in the normal view.
One way I found out is to set the TFS offline, make a copy of the database, bring the copy of the database online and then delete all projects that are still active and rename it. After that bring back online the original database and delete all archived projects.
This can be done once. Maybe once a year, but it will result in a large number of databases. This will make it worse than leaving the inactive projects in the workspace.
Does anyone have better idea? Or: What do you do with old projects?
First, there currently is no archiving function on TFS. However you can use something else as a workaround. To do this, you can either create a project designated as archived that you then have to assign permissions to and so on or move the project into another collection using the TFS Integration Toolkit.
Set the Read permission to Deny of contributor group will hidden the collection to come up in the normal view.
Below are some related blogs for your reference:
How to: Archive Team Foundation Server Team Projects
completely archive a TFS2012 project
Moreover, there has been a feature request in UserVoice, you can also vote up it to get more attention.
The process you are using (cloning a collection) would be the only method to achieve an archive as you describe it.
I would start by understanding why you have so many projects! Prefer larger Team Projects that contain many Products, Projects, Teams that are easier to manage.
I need to create a new project from an existing one in TFS. This is for source control only. I do not need to copy any work items.
so now i need to create NewTeamProject in NewProjectCollection and use the source branch of OldTeamProject in OldProjectCollection.
Kindly advise to go ahead with this.. Thanks a lot for your help in advance..
Manual Split
Create a new team project in your existing collection
Pick the branch from team project option in the creation wizard
Follow the split a team project collection guidance
However, I have a feeling that this will not bring all the history along with it, and it's not a particularly nice option, especially when it comes to the collection splitting.
TFS Integration Tools
Another way is to use the tfs integration platform, which basically replays all the checkins on a new team project, which can be in your new collection. You will lose the original date/time of the checkin, due to the way this program works but will still be able to see what each checkin changed.
TFS Integration Tools
Tfs integration tools blog posts and references
There is one risky way to get your timestamps correct, by manually updating the database
In our current project we have four different TFS2010 Team Projects in the same Team Project Collection. The reason for this is that different parts of the project wanted to use different team project templates (CMMI vs Agile).
All projects now use the same template. Therefore we have now reached the conclusion that it would be better to merge the projects into a single team project. This raises several questions:
Is it possible / feasible to use one of the existing projects as the target project for the other three?
How do we move our existing work items into the new project whilst maintaining our area tree? We hope to create one root area for each of our existing team projects, and move all work items / areas underneath this root node.
Today we have work item links from one team projects into another - how do we keep these links when merging?
What is the best practice when moving the source code? One clear approach is to simply copy it to the new location, and locking and keeping the old team projects in case we need to access older versions of the code. But is it feasible to use branching for this, e.g. branching all existing code to the new team project? What kind of problems might this approach cause?
Thanks for your help!
Unfortunately, TFS 2010 doesn't allow you to merge team projects.
Stucturing Team Projects and Team Project Collections is one of the most important strategy decisions to make before starting to use TFS. Unfortunately, a lot of the customers we help don't make the up-front planning necessary and don't understand some of the limitations in TFS around merging, moving, splitting, etc. team projects before they start diving in to using TFS :(
When we have consulting engagements where customers want to consolidate their team projects, we end up having to do a lot of manual work to migrate the artifacts. We have built some tools to help us with this process for work items but for the most part it's a lot of tedious consulting work. The migration utilities always end up needing to be customized for each customer as well since they usually have different business rules for how they want to migrate.
Ultimately, a "migration" doesn't end up bringing over all of the information and you end up with some other problems like date/time stamps being different from what they were originally. (I have heard it referred to as a time compression issue with migrations.)
Some additional thoughts for each of your original questions:
Sure, you could theoretically use one of the existing team projects as the target for the migration of the other three. As long as you like the team project name and don't want to rename the team project. :)
This is where we have built custom work item migration utilities to assist our consulting customers. You would likely need to do the same.
This is possible as well with a custom work item migration utility. You can just keep track of the mappings between old work item IDs and new work item IDs and then add the links later once all of the new work items are created in the target team project.
That's ultimately up to you. I would do a "move" version control operation on the source code from the old team project to the new team project. This maintains everything. However, I would not delete any of the old team projects because that will cause the version control history to be destroyed as well.
It's not the best story for you but hopefully it will help your planning out some!
In Team Foundation Server is there a way to have work items in one project linked to other projects so they show up in the reports in both. We are thinking about keeping release engineering items in their own project and want them linked to the project they are actaully for as well. Is this possible? So for instance I would create the item under release engineering assign it to an engineer and then link it to Product X so it showed up as a work item for Project X as well.
This is possible in TFS 2010 at least: link tfs work item to different project
Not sure on the effects on reporting though.
Not out of the box as projects are discrete. However there is nothing to stop you from writing against the API to fulfill this need, although this would take some considerable work.
Now for the good news. If you keep your eyes here, you may find the answer in time. As I see cross project reports are planned in Rosario