Choosing A Branching Strategy To Fit Our Deployment Needs [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

Background

So, I've spent the better portion of the last month automating our web + db deployment using MSDeploy, SSDT and TeamCity. The only problem is that, for demonstration purposes, I've only worked from our trunk branch. Needless to say, this approach quickly falls down when you consider the need to have parallel development efforts (segregated by branches in SVN). This is where I'm stuck and hoping to find some help.

Our Situation

• We never have to support multiple, concurrent versions of our software
• The customer is always on the current version

What I've Come Up With (Thus Far)

As I see it, we really only need two branches in source control:

1. Current: trunk - from which deployment occurs
2. Next: the development branch for the current iteration

At the beginning of a new iteration, Current would be branched (lets call that branch Next). All development for that iteration would be committed to Next, while, concurrently, any bug fixes needed for the current version would be committed to Current. At a certain point, Next will be "done" and, thus, merged back into Current.

Deployment

As far as deployment is concerned, Next would never be deployed to any environment. Current, however, would be automatically packaged/deployed to an internal environment by TeamCity at a regular interval (every commit, nightly, etc.). At some point, one of those packages would be considered "good enough" and, thus, pushed down the deployment stream (through staging, production).

Caveats

Given the aforementioned process, the merge of Next into Current would warrant a "code freeze" on Current, during which no new bug fixes could be released to clients. This bug freeze would last until Current is considered "good enough" to release to clients, at which point Current would be tagged and the whole process would start over again.

Questions

1. Is this approach/line of thinking reasonable?
2. Where does this approach fall down?
3. Is there a better way to go about this?

Any insight/documentation is much appreciated.

Answer 1

Since there's only one version of the software, it would be easier to tag the trunk when you release to the customer, and continue development on the trunk.

You have no need for branching, except in the case where you have to make a fix to the software while you're developing.

You'd have to decide if branching for development is more appropriate for you and your development group than branching for production bug fixes.

Answer 2

I think the prime directive in these scenarios is that you must always remain able to quickly fix a production bug without having to deploy non-production code. I feel like the 'no bug fixes during Code Freeze' caveat kills your ability to be flexible and respond to problems as they (inevitably) emerge.

Our process is pretty closely aligned to yours. We've had good success with a strategy like this:

Trunk is the trunk.
Prod is branched off the trunk. Prod revisions are tagged, and we deploy from those tags. Bugs are fixed and deployed from this branch; those fixes are merged back to trunk.
Next is one or more feature development branches that are reintegrated into the trunk as they're completed.

When we're ready to ship, we make a new Prod and the cycle starts over.

We like this model because:

• we can deploy production bugfixes at any time and without fear of incorporating unbaked code;
• it's easy to get those production bug fixes back onto the mainline;
• our trunk is essentially a log of merges and stays pretty clean. At any point the trunk could reasonably be branched to Prod;
• we delete the feature branches following reintegration, which is cathartic and satisfying.

Our managment likes this model because we can respond to problems quickly and with a low likelihood of regressions.