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.
Related
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.
I want to create a new stream in TFS just like we use to do in clear case or clear quest tool by IBM. I believe we can achieve the same thing by creating a branch. I have been able to create branches but than when we create work items , we are not able to search work items for a particular branch . Work items are coming in root project only. Here is my structure
Root Project
- Main Branch
- New Branch
Am i doing it right way? Do i need to create a new project and branch there right under root level ? Like below
Root Project
- Main Branch
New Project
- New Branch
I hope i am able to clear what i want to achieve . Any TFS expert there?
TFS has work item tracking features designed to assist enterprise software development teams to manage their work and software defect tracking. Work Item is for a team project's team, not for a single project/branch (team project and project are not same thing). You can specify Area and Iteration for a work item.
Regarding TFS branch, you would never branch a team project, but branch a project. Check: Branch strategically. You can use branches to accomplish the following goals:
Manage concurrent work by multiple teams on the same codebase
Isolate risks that are introduced by different sets of changes to the
codebase
Take snapshots and then support subsequent isolated changes (for
example, to create a release branch)
I have the following structure:
$/ProjectA [Uses MS Agile Template]
--Branch1
$/ProjectB [Uses Custom Agile Template]
--[To Be Created Branch]
How can I create this new branch in ProjectB that has a parent relation with $/ProjectA/Branch1?
Our requirement says that we cannot be under the same Project because we must use different templates, but we still want to merge the code from new project back to the ProjectA. I checked the option in TFS when you create a new Project that lets you use an existing source control, but problem with that is:
1.There is NO option to bring in specific branches in a Project [Its all or none]
2.I cannot rename that new branch in the new project for some reason
I understand this can be achieved by using a Baseless merge between these 2 projects but I would like to know if there is still a way to have a smooth merge between these 2 branches in different projects.
P.S: we are using VS 2010 with TFS 2010
There's shouldn't be any problems in just branching from one team project into another. You should be able to do this just like you would any branch: just select $/ProjectA/Branch1, select Branch, and enter a branch target path of $/ProjectB/ToBeCreatedBranch.
This is because realistically, Team Projects are of fairly limited scope in TFS version control - it primarily treats the source control tree as a big hierarchy beginning at $/, and team projects are not particularly special, except for some very specialized operations. (Check-in policies are queried for by Team Project, as are settings for locklevels and labels are scoped to Team Projects.)
I'm a little unclear what version control options you specified when you created the new Team Project - you should have just created a new source tree node for it and then you can create your project branches beneath $/ProjectB.
I would like to know what is the concept of Team Project in TFS 2010. In my company, there is a single team working on multiple products at the same time. There is a visual studio solution for each product. We are following SCRUM methodology. Our product back log and sprint back log basically comprises of items related to multiple products, so during the sprint the team works on backlog items relating to multiple products. We are looking forward to use SCRUM Process template for TFS 2010.
I was wondering what approach should i take in terms of organising the projects in TFS Source Control and making full use of the TFS Process Template(SCRUM)?
Should I create a Team project for each product? But that would mean I will have to maintain process template, product backlog and sprint backlog for each Team project. Especially when creating and querying work items, it will involve lot of switching between team projects in team explorer. Similarly, when creating burn down charts/reports, there is going to be one for each of the Team project. This seems like a nightmare!
Or should I create one Team project and put all the products(Visual Studio solutions) under it? This sounds better to me because, there will be one process template, one product and sprint backlog and one place to look at/query all work items.
To me it seems like Team project should map to a Team and not to a Product or Visual Studio Solution. However in my past experience, I have come across places where Team Project is mapped to product/visual studio solution and I am a bit confused.
The term "Team Project" is confusing. I really wish Microsoft had used a different phrase.
Having said that, I don't know what other word or phrase would apply.
A Team Project does not necessarily correspond to a Visual Studio project or solution
A Team Project certainly doesn't correspond to what SourceSafe used to call projects (those were just folders)
A Team Project doesn't necessarily correspond to a single source control tree. The people working on a Team Project may use code from multiple source control trees (assuming this can be mapped into your workspace correctly).
A Team Project more closely corresponds to an endeavor of some kind. This may or may not involve some source code. It will involve some people. It may or may not involve some work items, or builds, or reports, or portal sites, or lab environments, or any combination of those artifacts that are scoped on a per-team-project basis. These will usually be artifacts that will be useful to some "Team" in accomplishing their "endeavor" (which may just happen to ba a matter of producing and releasing some code, using the help of work items, reports, source control, builds, etc.)
I would advise you to create one team project and multiple folders for different solutions.
In other words leave your work as it is and create just one team project.When checking in products codes use server folders. This way you have a unique repository with shared work items and reports
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.