I'm trying to migrate my existing code to TFS 2013 Express.
I have single Team Project Collection and inside it 3 team projects:
-web
-winforms
-wpf
If I add project web-project1 (solution) to team project (for example to web) and check in I get info that change set 1 was saved.
If I add another project (winforms-project1) to other team project (winforms) and check in I get info that changeset 2 was saved.
If I return to first project (web-project1), change something and check in I get information that changeset 3 was saved, but this is my second commit to that project.
Can I configure TFS to have changeset incrementation counter for individual projects instead of one global counter for Team Project Collection?
No, TFS changesets exist across the whole TeamCollection, so are shared amongst TeamProjects.
This allows you to copy and move projects with history and changeset info across TeamProject boundaries.
In your specific example, creating a Web & Winforms TeamProject sounds like you are going about it the wrong way and are starting off at too high a level.
Surely your UI projects could share Business Logic code? Therefore, they should belong in one TeamProject.
Related
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.
I've recently completed the deployment of TFS 2015 Update 1, we have around 15 development teams in the UK and previously we have always structured our TFS projects as follows:
Default Collection
Application 1 (Team Project)
Application 2 (Team Project)
This caused issues with sharing work items across teams as it is difficult to move WI's across the project boundary.
Rather than create a new team project for each team, I want to manage things with a single team project and create separate areas\iterations\teams for each one. So:
Project Collection > Master Team Project > Area 1
Area 2
Area 3
etc
in terms of permissions I would like to add in each of the standard TFS permission groups to each area. I would also like to create a root folder for source control for each area.
At the moment I can't work out how to do this? Can anyone help?
I suggest you to look at the some community suggestion on this topic.
One Team Project to rule them all
Why You Should use a Single (Giant) TFS Team Project
How to implement a multiple team strategy in Team Foundation Server 2013
In general it is a good practice (I won't say best practice as it is not the right thing to do in some cases).
Regarding you question, you should focus on Team to define developers access, and TFS groups for general (e.g. administrative) access.
I'd recommend you to use the multiple teams feature in TFS2015. It allows you to manage the team members, permissions, work items more easily. And you can track the entire project status from the team project page and track the individual feature team status from their own project page. The work items can be also moved between the teams easily (Just change the area path). Refer to this link for details: Multiple Teams
I have a PBI in TFS under ProjectA with an iteration and area value filled in. Is it possible to move this PBI to ProjectB without creating a new PBI?
I am not seeing a way in the Visual Studio UI to do this. If I try to manually type in the area path of ProjectB, Visual Studio says that the path cannot be found.
I am using Team Foundation Server 2013 and Visual Studio Ultimate 2013.
No. Work items cannot be moved between team projects.
The reason is simple: The process template of the team project defines the work items. Team projects can have different templates. What if you tried to move a work item from a team project using a Scrum template to one using a CMMI template?
I would go a little deeper and say that if you need this feature then you should not have two Team Projects in the first place.
http://nakedalm.com/one-team-project/
The term that I use is:
"If you have artifacts that interact, with artifacts defined as people, code, or work items, then they should be in a single Team Project"
http://nakedalm.com/creating-nested-teams-visual-studio-alm/
Using a single Team Project can give you many more capabilities at the backlog/ work tracking perspective. Like the nested teams described above.
EDIT: This does not work for TFS2017 and forwards.
Yes, see http://www.codeproject.com/Tips/1018002/Yes-You-Can-Move-TFS-WorkItems-Between-Projects for a downloadable utility, source and a more detailed explaination.
It is a backdoor, SQL Manager approach, not supported by Microsoft, but it works for me. Here is the SQL:
UPDATE [Tfs_xxx].[dbo].[WorkItemsAre] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
UPDATE [Tfs_xxx].[dbo].[WorkItemsLatest] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
UPDATE [Tfs_xxx].[dbo].[WorkItemsWere] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
With the Tfs_xxx being replaced with Tfs_<your collection database name>.
Essentially, the project is inherited from the Area and the Iteration. Changing these from the current project to the target project causes the workitem to "move" to the target project. Additional rough edges are that the assignment pool or the workflow states might not align and have to be edited mannually in the UI to get the workitem back in the flow of the target project.
See my related answer.
Though not applicable to TFS on-premise, one can now do this with Azure Boards in Azure DevOps.
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.
We're starting to user Team Foundation Server and my boss would like some way to "archive" projects. Meaning after they are completed, remove them from an "active" state so that only "active" projects are visible.
Does anyone have any experience with this?
I've thought of 2 options.
1) Create 2 base projects. 1 for active projects and 1 for achived projects
2) Remove all users from the archived projects.
Thanks,
Sam
I would personally recommend waiting for TFS 2010 when more functionality will be introduced that will assist you in the ability to "archive" Team Projects.
In TFS 2010 you will hopefully be able to move a team project to a new Team Project Collection. Actually you do this by duplicating your "active" project collection and then deleting all the team projects from it apart from the one that you want archived. In this active project collection, delete the archived project that you have a copy of in the duplicated project collection. This archived team project will then live in it's own project collection which means it has it's own database etc which can be easily backed up / archived etc.
The archived team project project collection can then be left as it is as it doesn't slow down the server any if not being used - or it could even be detached from the TFS Application instance so that it doesn't show up at all and re-attached at any time.
An advantage of using project collections in TFS 2010 is that full Version Control and Work Item Tracking history will be maintained.
I would use it just as you normally do, but when you are done with the project then you remove it from the visible list. (In Visual Studio you can right click on a project in the team explorer and say remove.)
If you are worried about changes after the project is done, then remove the users from the contributors list. If you really want to boot the users out (so they cannot even see it) then you can deny them rights to the project.
This way you don't have to see it, but you can keep all your projects on the base level.
I would NOT recommend having just 2 base project for active and in-active. A TFS project should not be based on a state.
We created an "Archive" team project and we regularly move unused source code to that team project. It has worked out well for us, the history is preserved so we can always reference the archive project for old code or information on past changes. We also limit access such that developers have read access but only TFS administrators have write access. I haven't checked to see how these moves impact the association of check-ins with work items - mostly because everything we archived was checked in before we moved to TFS.
As for the one active team project, I was led to believe by knowledge experts and online documentation that this wasn't the best way to organize team projects. I think ideally you group projects/solutions together into a single team project if they are related (i.e. by line of business or dependencies).
I'm sure you've already done your research, but there is plenty of documentation out there that might assist (especially if your team maintains a single application or a handful of applications). I would suggest starting with patterns & practices: Team Development with TFS.