In my department we are developing several smaller AddOns for some unified communication server. For versioning and distributed development we use a Team Foundation Server 2012.
But: there is only one large TFS solution for all of our applications and libraries:
- Main Solution
- Applications
- App 1
- App 2
- App 3
- Externals
- Libraries
- Lib 1
- Lib 2
- Tools
- Applications
The “Application” path contains all main applications. Those are not depending on each other, but they depend on the Libraries and Externals projects.
The “Externals” path contains some external DLLs referenced in our Applications and Libraries.
The Libraries path contains commonly used libs (UI templates, Helper classes, etc.). They do not depend on each other and they are referenced in the Libraries and the Tools projects.
The Tools path contains some helper programs like setup helpers, update web services, etc.
Now, there’s some major points why I’d like to change this structure:
- We can’t use server builds.
- It’s uncomfortable to manage TFS scrum management with sprints, impediments, etc. with a solution structure like that.
- Every developer always has access to all projects in the solution.
- A complete build lasts too long if one accidentally hits [F6] in Visual Studio…
What would you change in this solution? How would you break those projects into smaller Solutions, how should those solutions be structured.
My first approach would be, to create one TFS project for each Application, Library and Tool. But how can I ensure that e.g. App 2 always contains the newest version of Lib 1? Do I have to monitor changes on Lib 1 and update App 2 manually as soon as the Lib changes? Or can I somehow force Visual Studio to always use the newest version of an external project somehow?
Edit: On the TFS, there’s just one TFS Team Project Collection, containing one TFS Team Project. The Team Project contains one large Visual Studio Solution, which contains several folders containing (see the structure above) with each of them containing multiple VS projects.
My question is now, how would you re-organize:
- The TFS Team Projects
- The VS Projects
0
Stick with one TFS Team Project, having multiple becomes a pain when trying to upgrade and has some limitations when it comes to cross team project work items. Instead you should be making heavy use of Areas and Iterations.
Split your VS Solution into multiple solutions, one per major application. This will speed up local builds a lot, as well as the build server.
TFS2012 has a new concept called Teams, create a team per application and set default iterations and backlogs for each. This way you can manage the backlog for each, or view the root team to see a rolled up backlog. Then you can manage sprints either at an application level, or overall depending on what suits you.
Create NuGet packages for all 3rd party referenced libraries that don’t already have one. Store them in a private repository (windows shared folder) and enable the package restore feature for NuGet by right clicking every solution and enabling it (also allow package restore to download packages in vs settings).
If you have any shared internal libraries then create NuGet packages for them also, and create a vs solution just containing that library. Add a post build command to create the nuget package, or extend your tfs build template to do it (there’s a number of templates out there that already do this).
1