CODEWITHSUNDEEP
.netbuildtfsmsbuildbranching-and-merging
Joshscorp
Joshscorp

Reputation: 1832

TFS Branching / Source Control Strategy

I am currently starting up a project for .net with many disparate parts, aka

1) Web Service API
2) Web Portal
3) 2 Windows Services + 1 Biztalk server
4) About 3 different Databases
5) Service bus connects them all via pub/sub
6) Client Web Application (Old) that already exists on another Team Collection to consume the web service api.

Each of the project areas are unit testable so that they can be isolated from their different messaging parts. I plan to do staging/prod deployment on AZURE. I plan to include Integration testing of some sort. There will be a CI / Build for every check in to include automated tests.

The entire application can only function when all parts are completed.

Questions

1) How should I structure my source control and branching strategy? I am thinking to have simply Dev/Main/Release Branch, should the 6 parts be in a single branch or should they all have their own Dev/Main/Release Branches? What about CI / Build / Versioning? Should they be versioned per part or per entire 6 parts together.

2) In terms of structuring tests for integration testing, where or when should I put the code in and run the tests? I do not think I can do integration testing until the very end.

Any advice would be great.

Josh

Upvotes: 1

Views: 410

Answers (1)

Paul Michaels
Paul Michaels

Reputation: 16695

This is quite a subjective question, but I can offer an opinion. Obviously, the best branching strategy for one person may differ for another depending on the team, the software, the testing requirements, etc.

My advice would be to create a single Main branch for the software, include all the unit tests in the project solution. When you come to do your first piece of development on a project, branch that project (or if they all need to be released together then branch them all) to a dev feature branch (effectively, just create a source controlled folder named Dev and branch into that for the feature).

When you've completed your development, merge that back into Main. It usually makes sense for Main to be a gated check-in. Once you've merged - delete your dev feature branch.

When you're ready to release, create a Release branch and deploy from there. If you need to manually test, then test your release branch. If you need to fix the release branch then branch off to fix, fix and then merge back; delete that branch after you've done so.

In summary, create one branch until you have a reason to create another; the dev/main/release branching is more conceptual - it's not intended to mean that you maintain 3 separate code bases.

Upvotes: 2

Related Questions