We have TFS 2015.
Is there guidance or a mechanism to move Test plans from one Team Project to another Team Project in the same project collection? From poking in MTM, it seems like you can clone a Test Plan, but the dialog does not allow you to specify a different target Team Project for the cloned Test Plan.
Cloning the Test plans with associated Test Suites and Test Cases would also be acceptable if the items cannot physically be moved.
TFS 2015 does not support moving work items between team projects, nor does it support cloning across team project boundaries. Your only option is to re-create the work item in the appropriate team project. There are various tools on the market that will create a new work item in the target team project and attempt to preserve most (but not all) of the history of the original.
VS Team Services does allow work items to be moved between team projects, however.
Move a work item to another team project is supported only from Team Services for now. Besides, you can't move work items associated with test management.
There has been a related uservoice for your requirement: Export test plan tree between projects and collections in MTM
We have enabled both Test Plan and Test Suite clone capabilities
within the product. See
https://msdn.microsoft.com/en-us/library/hh543843.aspx
This allows you to clone test plans/test suites across projects within
a collection. For moving artifacts (including test artifacts) across
collections, you can use the “TFS Integration Platform toolkit”.
COMPLETED · Visual Studio Team (Product Team, Microsoft Visual Studio)
You could only do this in MTM, could also use Tcm.exe command to copy test suites.
Related
I am looking a tool that can move the test cases around 100+ with entire data from one team project collection to other.
Along with the above one I need answer for below quesries:
Can we copy the DB tables with the test cases in it from source project collection to target one?
Can I download all of the Test Case data from the source Team Project Collection into a Spreadsheet and then upload the spreadshseet into the target team project collection?
Is there any tool that can support above mentioned scenarios?
Check the WI Migrator tool, it's a great tool (and free up to 250 work items).
WI Migrator performs a migration of TFS work items environment from a
Team Project to another, cross TFS collections / servers. WI Migrator
duplicates the work items, restores the links between them, and
recreates the test plans and the test suites. Attachments included.
I suspect we have a common hierarchy with many other business in that we have software products and we enhance each product through a series of projects.
We have TFS2015 which we host ourselves.
Given TFS does not seem to support the idea of Product I created a TFS project called MyProduct. This 'product' exists in both ALM and SCM.
Next I created my first real TFS Project, i.e. I created a TFS project with the same name as the actual project I have to run for my job. I now have two TFS projects,
MyProduct - this is my master TFS project which I treat as my Product
MyFirstProject - this is my first actual project which I'm executing to enhance my existing product
The source code for MyFirstProject is a copy of the source code in MyProduct and should be merged back to MyProduct at some point or points.
When I am at the end of MyFirstProject I want to move the open work items into my Product TFS Project, i.e. MyProduct, including,
Descoped MyFirstProject stories which I want to keep in my product backlog
Bugs which are detected but not fixed in MyFirstProject
Epics/features which are added during MyFirstProject
Next I want to start MySecondProject, etc etc.
Hopefully this is enough detail around how I believe regular products/projects work and my question is, am I using TFS correctly with this approach? It does not seem natural in that my new TFS projects are not an SCM branch they are a new SCM project and moving work items between projects isn't an obliviously easy thing to do.
It feels like I'm missing the point of the TFS project structure.
I'd like to introduce Team Project Collection and Team Projects.
A Team Project Collection is a group of team projects. When you install TFS, a default collection is created to contain all team projects.
A team project is a collection of source code, work items, build
definitions, release definitions, manual tests, etc. You can have
multiple Team Projects per Collection. You create a team project to establish a repository for source code and a place for a group of developers and teams to plan, track progress, and collaborate on building software solutions. Team projects differ from software application projects or solutions. (Please clarify the TFS project you mentioned in post is a team project or oftware application projects.)
According to your description, MyProduct and MyFirstProject should have branch relationship. So you can create a project A under a team project X, then branch project A to meet your requirement.
Work items is under a team project, not a single software application project. In order to achieve what you want, you can create Teams and Areas and assign work items to different Area.
We are using TFS on premise, version 2015 update 3. We are using multiple team projects. Some Team Projects are used for applications (source control and builds), other team projects (with multple teams in it) are used for work item tracking. Teams can work on different applications.
Now we are looking into the Release functionality. Preferably we would like to use 1 team project to keep track of all the releases, so we get an overview of all releases in our organisation. But I can't figure out how to achieve this.
Is there a way to define release definitions linked to builds from an other Team Project? Here Microsoft says: "No additional setup is required when deploying Team Build artifacts published within the same team project." So I guess it should be possible to do an additional setup, but I can't figure out how.
We also have many team projects
We are using TFS 2015 CU2 but I do not think there are to many differences between the two versions.
The artifact link are for team builds within the same team project. I do think there is a way you can link to builds outside to other team projects.
In your one team project you could create all your CI builds there (in the build defintion mappings would can map to any source control path you want you simply have to cut in the path.)
If you still using your XAML build definitions; you could use the TFS Communinity build manager add-in for VS 2013 and clone the build defnition to you new team project.
So there is not easy way currently. We have chosen to release from every team project. The release overview is nice but we chose that it was not worth the effort. Maybe in the next release we will revise.
You shouldn't separate aspects of your project (builds, code, releases, work items, etc) into different team projects. You lose all tracability if you do that, as you're seeing.
You can manage your application portfolio within a single team project with the appropriate use of Teams, but discussion of exactly how to achieve that is going to be very specific to your organization and thus is too broad to discuss on Stack Overflow.
Our team has an a TFS project in which we keep all the teams work. Sometimes some from our team are involved in another project that has it's own TFS project. The tasks that the people from our team does on the other project are in their own area.
Is there a tool that would support synchronizing work items between projects and keep all fields the same value except Area and Iteration? Area would be statically mapped to some value and iteration would live it's own live in each project.
We use the same project template for all team projects.
There are a number of commercial tools, most notably TaskTop, to allow you to sync work items between projects. I have seen TaskTop work well in quite a few circumstances.
The TFS Integration Tool is a free tool provided by the TFS product team that can do synchronisation of work items.
We have a Team System environment where our applications are set-up as separate Team Projects. Often, we run into a scenario where a development task requires updates to code in multiple Team Projects.
In this scenario, what are the pros/cons to having a single changeset that contains coding changes across multiple Team Projects? What are the pros/cons to using a one-changeset-per-Team-Project approach?
Providing the changes are made within a single workspace and all the team projects are in the same project collection (this applies to TFS2010) then a single checkin can span multiple team projects.
Within a single server (TFS2005/2008) or team collection (TFS2010) there is a single version control repository with the team projects defining the root folders: all version control operations can span different team projects.
I see no problem with this approach. Remember that TFS will allow you to rollback to the previous changeset, or inspect the files affected by a changeset (comparing to previous versions) so you can rollback some or all of your changes if required.