I've recently installed and started using TFS. Mainly using for source repository initially and then will get into using the Work Item features. I'm moving from using Vault as repository and have some questions on best practices for setting up the project structure.
My current structure from Vault is:
Projects
- CustomerName1
-- Application1
-- Application2
- CustomerName2
-- Application1
-- Application2
Can I have a smiliar structure in TFS? Is there any good documentation that has real examples and
instructions on how to set this up? From what I see is all real basic and the books I have don't have real-life repository examples that mimic the structure I have.
I have created a new Team Project called CustomerName1, then added other Team Projects, Application1, underneath CustomerName1. However, I lose on the Application1 the separate folders like Work Items, Documents, Reports, and Builds.
So this doesn't appear set-up correctly.
Thanks ...
A few questions for clarification.
Do you have any shared assemblies between Customer1 and Customer2? If so, put a single Team Project and then add sub-folders in source control explorer for Customer1\App1, Customer1\App2, etc, etc. Also a shared libraries or some such parallel to the CustomerX folders.
Do you have an existing branch/merge strategy?
You will have shared SharePoint sites, Builds, WorkItems, Reports, and Documents by default for the Team Project. You will have shared TFS Databases in SQL (effecting WorkItem numbers) for Team Project Collections.
You can, however, set permissions for any user/group to folders via Source Control Explorer.
Related
I am installing TFS 2018 on premises and I want to try to enforce some logical folder structure where all of the deposit related projects\development are in the Deposits folder. All of the lending in Lending etc. etc.
I created two collections one for testing of the tfs installation and a production collection. It seems you can only create Team Projects in a collection. Is there no way to create a hierarchy?
Or how about a sub project? I don't want to have a team project for every single task. Some tasks are tiny while others are large multi programmer projects. And if I create a Team project for say Deposits and have folders for each task\project then won't I lose the extensive amount of ALM features for projects? I mean, won't they comingle when they are all under one project?
I must be missing something. Even sourcesafe allowed you to create a working folder. thanks
Hierarchies are established within team projects. A team project is a portfolio of related applications.
Use teams, iterations, and area paths within a single team project for organization of work items. Iterations define your schedule for work, and area paths allow for organization of work items for filtering and assignment to specific teams.
For source code, if you're using TFVC, you can either create folders within a single team project and enforce access via security settings, or create separate team projects for each unrelated suite of applications.
A typical TFVC structure within a team project would be something along the lines of
$/MyTeamProject
/ApplicationX
/Main (trunk)
/Dev (branch from Main)
/ApplicationY
/Main (trunk)
/Dev (branch from Main)
Or if ApplicationX and Y are related and need to be branched together, you invert the structure:
$/MyTeamProject
/Main (trunk)
ApplicationX
ApplicationY
/Dev (branch from Main)
ApplicationX
ApplicationY
For Git, you can either keep unrelated applications in separate repositories, or adopt a monorepo approach. Each approach has advantages and disadvantages and will require you to do some research to decide which one fits your use-case.
Looking for documentation about moving only a subset of contents from a TFS 2018 server in certain domain and hardware to another TFS 2018 server in another domain and hardware.
More Details :
It is possible to follow general instructions for migrating a tfs to another server/domain, but we need only a subset of the contents i.e. contents for specific team projects in the single default collection that we have. The existing documentation in microsoft docs relates only to all the contents as a whole. We'd thus also like to assess whats recommended : migrate all and delete relevant contents on target or migrate only relevant contents from source to destination. Contents include : code, work items, Build & Release, all history, etc...
There's no way split individual projects out of a team project collection without resorting to third-party integration tools and suffering from a lot of pain.
The best solution is to clone the team project collection using the standard process, migrate it, then delete what you don't want.
What is the recommended organizational structure of team projects in TFS 2010? Let's say we have 4 big departments within our enterprise. Is the recommended approach to create a team project for each department or logical representation of one's organization and have different folders for VS projects within those TFS team projects? Or should each reasonable big project have their own team project?
I am asking more from a perspective of code storage and TFS artifacts. If we are to store both code and user stories, tasks, etc. in one big team project, does that hinder the agile development process? We can still setup separate queries and a separate dashboard for each "project" within the big team project. However, the builds would be in this giant list of builds.
If we had many smaller team projects, it would be more difficult for QA to span their work across multiple team projects. They'd need to know where to enter bugs - knowledge that we don't necessarily want to rely on.
So what is the best practice?
Storing everything in a single project will not hinder "the agile development process". My recommendation would be to create an area path for each project, and organize your work items under those area paths. You'll have a product backlog query for each area. Use the iteration path field to then drive a schedule across all the projects. That should work fine. All the reports can then be filtered by area and/or iteration.
For builds, I see many teams prefixing build definitions to provide better organization. Here's a blog post that describes an extension you can download to help better organize builds.
http://blogs.msdn.com/b/bharry/archive/2011/04/01/build-folders.aspx
We have a project that will be developed in multiple phases over the next 12- 18 months. It's an agile-esque project in a waterfall environment, it that matters.
My initial thought was to create one team project named 'Project X'. Under Project X could be multiple solution folders but the main development would be in a folder called Main. Branching would be done as appropriate.
The other solution folders under the Project X team project would be for some of the tools we need to build for this project that are independ of the main app, which is a web app. For example, we needed to build an app for processing data and sending it to a web service but it never interacted or merged in any way with the main web app.
The advantages I see to this approach are a) all the code for the project is kept under a single team project and b) all the work items, bugs, wishlist items, are accessible from all the other projects.
Does this approach make sense? Any ideas to improve this? I haven't created the team project yet.
I will simply comment on the advantages you listed to help you understand why this approach isn't ideal.
The advantages I see to this approach
are a) all the code for the project is
kept under a single team project and
Both your tools and your web application are for "This project." That right there is a key indicator that you should use one Team Project inside of TFS. You gain nothing by having two separate Team Projects. In fact, you may make it more difficult to manage.
Consider if you have a requirement that has work one both a tool and the main application to complete. In your scenario, there would be no way to track work history associated to one requirement because you are using two Team Projects. There are many more reasons, you have to manage permissions in two places, have two sets of mappings etc etc.
I would highly recommend you opt to use one Team Project. You, and your entire team, will thank me later.
b) all the work items, bugs, wishlist
items, are accessible from all the
other projects
If you have two Team Projects, you cannot access WIs etc across the projects. In fact, you will have the exact opposite- you will have to create the WIs in both projects if the work crossed over between the two.
You should have one Team Project. A folder for the tools and a folder for the web application. From there you can take it further having it branched off- a branch for development and a branch for main is a good start. Inside each, have the tools and web application so the versions stay in sync.
Here is a good place to start reading before setting up your project: Microsoft Team Foundation Server Branching Guidance.
What you're describing is not a Team Project. You're simply describing the structure of some source control folders in TFS.
A Team Project is a lot more than just source control. From T (Visual Studio ALM Glossary):
team project
The named collection of work items,
code, tests, work products, metrics,
and so forth, used by a defined team
with Visual Studio Team Foundation to
track a common set of related work.
I'm migrating from VSS to TFS 2010 and using that as a good opportunity to review how we organize projects in the company.
Our company deals with two market segments, let's say Sports and Industrial Inspection. Since there's a low likelihood of sharing projects or code from one codebase to another, I created two project collections, one for sports and one for inspection.
The thing is that developers are used to the VSS way of organizing projects by creating a directory tree where the projects go.
How that concept migrates to TFS?
I find TFS branching guide to be a good starting point for project structure in TFS. Look at the TFS_Branching_Guide_Main_2010_v1.pdf file in the zip that one downloads. There are some good examples in there.
I think that splitting the two market segments into two project collections was a good idea. Keep in mind your project structure in each collection if you are planning on using the TFS Work Items. Most work item templates that I am aware of only allow project tracking by team project. For example: If your development team is working on two projects at the same time and you wont be able to run separate TFS project tracking reports for each project. In that case you will need to create a collection for each project.
Once you have all your files ported over from VSS in a directory structure you are comfortable with, I would then look into a branching strategy that your team agrees on.
I hope this is useful.