Search code examples
tfsnugetalm

Incorporating dependencies in a branching strategy?

I am looking into simplifying the current source code repository and solution setup. Right now it's very complex and enormous and making changes to even the simplest piece of code can be very time consuming.

For the sake of simplicity, let's say I have the following setup:

  • I have 1 website project (W1)
  • I have 2 web service projects (S1, S2)
  • I have 3 class library projects (L1, L2, L3)

They are managed by 3 solutions:

  • 1 solution containing W1, L1, L2, L3 and using service references to S1 and S2
  • 1 solution containing S1, L1, L2, L3
  • 1 solution containing S2, L1, L2, L3

All of this is currently controlled by 1 single source code repository in which I apply a branching scheme which uses a Main, Development and Release branch at all times.

As you can see the library projects are referenced multiple times, and, as one might expect, this sometimes leads to collisions when multiple developers are working on the same library. As I mentioned before, in reality I have far more library projects. Right now there are solutions which contain 50+ projects and almost all solutions contain the same projects. In order to make them more maintainable I would like to move the library projects into their own solution and create NuGet packages of them.

I also have three environments to which things are deployed:

  • A TST environment to which the Development branch builds are pushed on a daily basis
  • A QA environment to which the Release branch builds are pushed
  • A LIVE environment to which the Main branch builds are pushed

The problem I'm facing is that I don't quite see how I should incorporate the NuGet packages into this deployment strategy as development occurs on all projects during the course of one sprint and if a developer checks out a Release branch or the Main branch to create a hot-fix, I don't want him messing up the referenced NuGet packages and accidentally introducing a Development package into the Main branch.

From a build purpose, it's doable to simply use the same branching strategy when building the library projects and publish the NuGet packages of each branch to a different repository. From a developer point of view, I don't know how I can easily switch between multiple repositories. I can't bother developers with a requirement to modify their NuGet repository URL when checkout out a different project or branch.

So the question is: what's the proper way to actively develop a set of libraries and front-end projects in parallel?

I don't think what I want to do is that difficult or that I'm alone in wanting this. Yet I don't find any relevant documentation about this. Am I looking at this entirely wrong?

Solution

  • The answer is actually quite simple.

    In my case the best solution is to define different package sources per branch in a NuGet Config File.

    <packageSources>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    <add key="MyRepo - ES" value="http://MyRepo/ES/nuget" />
</packageSources>

    I can create a different NuGet repository per branch, create a different NuGet configuration file for each branch and simply define the correct repository URL in that config file.