We're working on getting better use out of our TFS/TFVC server and move to benefit from TFS Work Items, and I have been put in charge of figuring out how to do so.
We have a lot of projects, most of them working with common code libraries. Our way of implementing new features have been to just include a reference to the code and build it all together when changes are needed, instead of referencing DLLs for the libraries.
My question revolves around setting up workspaces that don't end up making this a hassle when updating code in common libraries as well as the main project being worked on.
In working with this briefly, I have created multiple team projects for each product we're developing and it looks like the individual developer has to make sure to move between all the workspaces connected to the individual project and check in code for each of them. I feel like this is clunky and that there must be a better way to get this done.
A structure could look similar to this:
ROOT
|- Common Code
|- Team projects (each having their own backlog and referencing "Common Code"
|--- Product one
|--- Product two
|--- Product three
Would a better approach be to work on a single workspace and just create teams and have backlogs for each or is there a clean way of allowing the developers to utilize a common code library from individual Team Projects?
There are a lot of considerations going into the setup of your team projects. The most important reason to separate out to different project is security. If you have a need to ensure that different projects can't see the metadata of other projects, then a single Team Project is a bad idea.
If your teams have major differences in the process they follow, they may also have a need for different Team Projects, as the Process can only be defined at the Project level and all teams under the same Team Project have to follow the same process (either Scrum, CMMI, Agile or a custom Process). It may be worth to move your teams to the same process template though, there are not too many differences between Scrum and Agile, so unless you depend on CMMI or a heavy custom template, you can practice Scrum and something other kind of Agile in either template with a little bit of fantasy.
In all other cases it may be valuable to consider creating a single Team Project and using Team Backlogs to represent your projects. This approach is commonly called the "One project to rule them all" setup.
As for your "common code" project, I'd personally consider using the Package Management features of Visual Studio Team Services to generate NuGet packages of changes made to common code. The ALM Rangers have written some guidance on setting this up in the past, it's not updated to the latest version of VS and TFS, but it does give a nice outline of the process. Then include these common libraries as NuGet package references to your other projects. This gives you more control over when specific projects upgrade to a specific version of the common libraries and it results in a nice separation between the different projects using the common libraries. After having done this, it's also easier to setup things like Continuous Integration, Gated Checkins etc. working with complex workspaces will make that harder as well as you'll find out.
So it'll look like:
If you move your projects to Git, it also becomes a little easier, as you can have multiple Git Repositories under the same Project.