I ran into a new branching strategy, branch by sprint, this week. I will have to admit it was a new one to me. I've seen branching by environment (dev, test, staging, prod), branching by developer, and branching by feature/user story. I had not considered branching for a sprint.
I started examining it to see if it might be a fit for my team's approach. I ran into a couple problems due to the structure of the systems my team works on. It may be specific to our situation but I'm betting our setup isn't unique in the universe.
In our sprints we don't always work on a specific product or repository. We may have two or three products (library classes, web applications, and services) involved in a single sprint. This means we would have to branch each repository to it's own sprint branch and merge those back to the master branch when the sprint concluded.
I'm a convert to a minimalist branching strategy, so this strikes me as administrative overhead to be avoided.
However….
If a team was only working with a single repository I can see some advantages to this approach.
First, it really helps the team focus on its definition of done. If code doesn't meet all the criteria for done it doesn't get committed to the sprint branch and therefore doesn't get merged back into the master branch for production deployment.
Second, it sets up a release cadence in sync with the team's sprint cadence. This may or may not be a problem for the organization but it can be a simple way to plan production releases if that question is one the team is wrestling with.
But the question of administration overhead comes up again in regards to build automation and user story carry over.
In terms of carry over, if for some reason the team did not complete all user stories in a sprint, the team will have un-merged work in the sprint branch. The new sprint should be branched from the master branch leaving the previous sprint work orphaned. This work would then need to be merged into the new sprint branch.
Merging isn't overly burdensome in and of itself but it is more weight added to the process in terms of additional steps to follow (and forget) to get the new branch ready to begin work. I know, I know, there shouldn't be carry over anyway but that's a contingency that has to be planned for. A contingency that because it should be rarely carried out doesn't develop expertise and is therefore more likely to have quality issues when it does happen.
It doesn't seem to me that the overhead is justified by the intended benefits.
It also complicates build automation. If the intention is to continuously integrate and continuously deploy code in a branch to QA this will necessitate the creation of a sprint build definition that needs to either be recreated for each new sprint branch or modified to accommodate the new branch. Again, additional overhead that doesn't seem necessary.
For now I'm sticking with our current strategy. Keep a single master branch. Developers create feature branches if needed for their work and only merge back to master when their work meets the requirements to proceed to QA. Build automation points to the master branch and continuous deployment delivers the build to QA and production after it is deemed ready.
I'd love to hear your perspective in the comments below. Have you encountered the branch by sprint strategy? Have you been successful with it?
