TFS - Continuous integration with branching

Question

Here is my scenario (TFS Online - username.visualstudio.com/repo):

I have a following folder structure

--$
  --TimeManagement  (.sln file at this level)
    --WebApp  (Main branch) (.csproj at this level)
    --WebApp-Dev (Dev Branch) (.csproj at this level)
    --WebApp-QA (QA Branch) (.csproj at this level)
    --TestTimeManagement (Test Project) 

With this, I create a build with default settings and my release option pushes success build to azure web site. This works perfect until I come with following scenarios:

• I would need same/only test project configured for main & Dev branch
• I need to have branch change specific build, so instead of .sln file, I want build should consider .csproj of branch.
• I can make changes under each build's trigger tab - continuous build - add filter with branch specific folders
• In this case, My dev branch changes will mostly execute build related and execute test & when I finally merge my changes to main branch, build related to it will execute with same test case.
• I tried to play around this, however, build was getting messed up with .csproj to solution option. It is not able to find test assembly - **\*test*.dll

In simple words, I am looking for setting up TFS (online, at this moment) where there will be multiple branches (dev, main, staging, qa) with single test project and configure builds, triggers on specific branch changes.

Doubt: Can we create branch at .csproj level or only need branching at .sln level?

If I get any reference doc/video, would be great !

Answer 1

Doubt: Can we create branch at .csproj level or only need branching at .sln level?

You can branch at any level you want: Solution level, project level, folder level and file level.

I have a set-up where we have multiple solutions and there are multiple projects that are either used by one solution or shared by multiple. If they are shared by multiple solutions and you make changes to the project when working on one solution, there is a possibility you may potentially break other solutions. Therefore, for this case, I have a master solution which has a CI build that builds all the projects to make sure nothing is broken.

Keep in mind, when you have many branches, merging becomes more complicated. I suggest you start with a simple 2 branch strategy: Dev and Main branch. If this does not work for you, then create more branches. Every day development can be done on the Dev branch, and when you are ready you can cut-off and go to Main branch. But before you merge to Main, make sure to merge up from Main branch to Dev and then merge down from Dev to Main: Always do this as a good practice.

There is a difference between environments (Dev, QA, Prod) and branches. The relationship need not be 1:1. So you can have 2 branches (Dev, Main) and still have many different environments.