VSTS terminology and structure

Question

New to VSTS, but not Git. Our small team has the usual mix of web apps, windows apps, other misc applications/services and we keep our database objects in visual studio sql server projects as well. So there are 15-20 or so different sets of code to deal with. Currently, each would have its own Git repo.

Was reading this post regarding single vs multiple "Team Projects". Then, I posted this earlier but was specific to backlog items, but I suppose my real question was about the bigger picture regarding the idea of a "team project"

What would be a good structure for a small team with this number of applications. Assuming each application generally is worked on independently, but you might want to build 2 or more of these applications together.

How about one team project. Multiple "teams", one per "application". Its the terminology that is throwing me off.

Can different teams each use a different repo?
Can each team have a different set of build definitions? eg. dev/prod etc

Answer 1

A team project is a container for a portfolio of related applications. A team project can contain one or more source code repos (Git/TFVC), builds, releases, test cases, work items, etc. All of these entities have ways of defining security around who can view/modify them.

A team is just an organizational structure within a team project. You can use security permissions to limit certain repos, builds (or build folders), etc to a certain team.

The generally accepted guidance is to keep everything in a single team project. There are lots of things that don't cross team project boundaries, such as repos. Work-arounds usually exist, but they are typically awkward.

The one requirement you gave ([we] might want to build 2 or more of these applications together) is actually slightly tricky regardless of whether the repos are in one or in multiple team projects -- a build definition can be hooked up to a single repo. If you need to bring in additional repos, you'll need to use submodules or add an extra build step to clone the second repo. I can almost guarantee it'll be easier if everything is in the same team project, though.

The one-word answer to the two direct questions you asked is "Yes."

Answer 2

How you set up your structure is really depending. There are many ways to organize it. Single repo, multiple repos.

If you are using CI builds, have in mind that the get sources task in your build will download your full repo. So if you have a single repo strategy your build could take longer to run. In this scenario you would also have more work to setup your builds and specify path filters to trigger only the correct build on your CI process.

Can different teams each use a different repo?

Yes they can.

You can create a security group for each team.

Then, on you team you can remove it from Contributos and add your new group as part of Member of:

After that, in your version control settings, add your new security group and remove or deny access to Contributos security group. This way, only your team security group will have access to the repo.

This is optional. You only need to do it if you want to isolate access to your repos.

Can each team have a different set of build definitions? eg. dev/prod etc

You can setup a build for each of your repos. If you need to isolate who has access, you can do it by changing the security on each build, removing contributos and adding your security group.