The TFS to VSTS Cloud Migration Guide contains the below Project Limits paragraph. Can "project" in the context of the below stated VSTS limitation equate to "git repository"? We have an on-prem collection with 323 git repositories in it already and I want to be certain if the below limitation applies to our situation and would cause us to have to split our collection in order to move to VSTS.
Project Limits
Customers with a large numbers of projects in a collection should note that VSTS has a limit of 300 projects per account. Above 300 projects certain experiences, such as connecting to the account from Visual Studio, start to degrade. If your collection has more than 300 projects then you will either need to split the collection or delete older projects to get below the limit.
Team Projects are not the same thing as Git repositories. If you have 323 Team Projects, each with one Git repo, then yes, it applies. If you have 1 Team Project with 323 Git repos, no, it doesn't apply.
There is a soft limit of about 300 Team Projects per Team Project Collection. Unlike TFS, there is only one project collection in VSTS for now. A related uservoice：
Let us create multiple collections on Visual Studio Team Services
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/3473653-let-us-create-multiple-collections-on-visual-studi
So the project here means Team Project. The scope of a team project should be things that are related to each other. When you work on a product that is very closely related you want to have everything in a single team project. Usually we wouldn't create so many team projects, 300 is a large number of it.
For more info about team project, you could refer this tutorial in MSDN.
Git repositories is not equal to team projects, multiple git repositories may only belong to one team project. So you don't need to pay attention to how many git repositories do you have in your on-prem collection, just pay attention to the number of team projects.
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.
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.
How do I organize many projects on Team Foundation Services (TFS in the cloud).
I have about 300 solutions (with multiple projects in each solution) that I want to source control in TFS. The problem is how do I organize them?
A little background: I am an contract developer so I work for many clients and have many projects written in VB and C# ranging from VB6 to .net 4.5 and everything in between.
I think the key is to understand the organisational structure on offer to you with Team Foundation Service. How you choose to organise it is ultimately up to you.
You have the following available to you in Team Foundation Service.
One Project Collection
In normal TFS you can have many Project Collections. In Team Foundation Service (at the time of writing), you can only have 1.
Team Projects
These are the projects that go into the Project colection.
You can put many solutions into one Team Project or you can simply have one.
Source Control Folders
Each project obviously contains Source Control folders, so these could be further split up into projects.
I don't have as many projects as you, but I do something like this:
Create dedicated Team Projects for major projects (solutions)
Put similar minor projects (solutions) into one Team Project
You can even nest things further. I have included a real world scenario I use for the SSRS report we write.
See below for an example how I do it:
Collection (Project Collection)
Major Project 1 (Team Project)
trunk
branches
branch 1
Group Of Minor Projects (Team Project)
Minor Project 1
trunk
branches
Minor Project 2
trunk
branches
Minor Project 3
trunk
branches
Major Project 2 (Team Project)
trunk
branches
branch 1
Group of SSRS Projects (Team Project)
2005
Clients
Client1
trunk (Optional)
branches (Optional)
Client2
Client3
Shared (All Clients)
2008
Clients
Client1
Client2
Client3
Shared (All Clients)
2008 R2
Clients
Client1
Client2
Client3
Shared (All Clients)
One point to remember is that builds are separated by Team Project. So this might impact your decision further.
Since you are creating different projects for different clients I’d organize your solutions by client.
I’d have a total of one project collection and one team project per client. Then inside each team project you can structure the solutions any way you like.
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.