Branching Model for Agile/SCRUM Development

I have been working on a new simplified software configuration management branching model for SCRUM/Agile development that provides the benefits of the model traditional Continuous Integration uses with added benefits.

The model is a remarkably clean and inherent in this model is the elimination of regression. It utilizes three pathways. The first path is having a Definitive branch with is always maintained as an image of what is currently in production, and serves as the source for all future branches. The second path is used by the Sprints, and there are many and they are short lived, with their usefulness being one or two weeks, and their termination is there return to the Production branch. The third path is for the employment of the SCM model, known as the Long Transaction model, and is intended for major complex features spanning several Sprints.

Regression is eliminated inherently in this model because the current Sprint is based off of the same code baseline from which its predecessor finished, and which went into production. Another feature of this branching model is that the Sprint branch serves as both a development and release branch. In the past where a development branch is used continuously across several releases, you will find several features that were coded in preparation for an eventual “future” release becoming the source for a fix even though the intended future feature’s inclusion into production was scrubbed. In this model, only intended changes are added to the branch and there is never a doubt as to what features and fixes are on the Sprint branch. 

The model shown below as figure 1 is the basis of all variations to be discussed. It is based on the following SCRUM/Agile premises;

1.      All Sprints are delivered to Production on their due date, no exceptions.

2.      There are no concurrent Sprints, the next Sprint starts when the last makes its way into Production. Sprint 2 follows Sprint 1, and Sprint 3 follows Sprint 2 which makes them consecutive. 

3.      All Sprints have predefined and agreed work effort to be accomplished at the start of the Sprint.

Figure 1

While Figure 1 is maybe a text book perfect design on a branching model based entirely on the Agile’s rules, the one thing Agile does not account for is the concept of the long transaction model that is used to develop complex and major features that cannot or should not be subdivided into separate Sprints to incorporate only a fraction of the functionality into each Sprint. While an Agile solution is to break the feature in sub-Sprints and program the features and functionality that each Sprint can consume with functionality flags that basically turns on and off the feature’s functionality. This is not an ideal solution, as this method introduces an unnecessary level of development complexity, and often the feature is released with several flags dispersed throughout the feature still set shutting off fullness of the expected functionality. Because several components have these flag that have not been changed from development mode to production mode they create the perfect condition for “HotFixes.”. I would propose utilizing the long transaction model concurrently with the consecutive Sprint model.

The long transaction model that can be isolated from the consecutive model so that Agile’s workflow maintained is shown if figure 2a. With this model added to the basic Sprint model the work within the Sprints takes place regardless to the work being done on the feature, for the feature’s development is isolated from the Sprint. During the life of the feature the feature branch is constantly being rebased from all Sprints as the enter production. While isolated it is important that the feature be continuously developed in a code base that is as close to production as possible, and rebasing the feature branch with the code base that goes into production is critical to successfully using this branching feature to avoid regression and unnecessary complexity in merging the feature into the Sprint it will be release from. Even though this feature was developed by itself, it is still important it is release from a Sprint (Figure 2a), or as a proper and independent Sprint (Figure 2b.) The few minutes spent after each Sprint goes into production does pay off with a significant reduction in complexity when the time comes to integrate it into the target Sprint branch and assuring the elimination of introducing regression into the production environment.

Figure 2a

Figure 2b

The assumptions made in using this model are:

1.      There is one complete feature per feature developed on a feature branch.

2.      The feature branch’s code is never allowed to be skewed from the baseline that is in production. 

3.      Prior to introducing the feature into a current Sprint, the feature branch needs to incorporate the work already done in current the Sprint into itself. It is important this reconciliation is done on release branch, as represented by Figure 2c. This is done under the premise that the Sprint branch must be released into production on schedule and any instability should not be intentionally introduced on to the Sprint branch. Any possibility of instability should be kept in isolation on the feature branch and resolved there. Only at this point the feature is prepared to be injected into the current Sprint. Following are some practices to consider prior to merging onto the Sprint branch:

a.      A code freeze on the Sprint branch is called for in order to make the Sprint branch quiescent so the injection of the feature is smooth. This is so a rebase can be performed so that the baselines of the two branches are equal, and merging the feature is not complicated by skewed baselines.

b.     Prior to releasing the Sprint Branch to Production a new set of tests will be performed to insure the integration of the feature is successful with the Sprint. At this point it is not important which branch you test from, as the Feature branch has been rebased, and the Sprint branch is quiescent and had been locked from further fixes. (Hint – Your major feature should be the last thing on your Sprint branch.)

Figure 2c

The last condition to consider with a simplified and unified development branching model is what should to be done with the occasional Hotfix. Hotfixes by the very nature occur in Production, and is based off code that is in Production. It is there for proper that the code base used at this point is from the production line, as all Sprint branches upon incorporation into production are locked and now obsolete and the next Sprint’s branch has already been cut. 

In figure 3 a HotFix is introduced into Production but now the Production branch has deviated from the source of the current Sprint branch and current Sprint’s baseline must be brought back to the same baseline as what is currently in production or regression will be imminent as soon as the next Sprint goes into production. In this situation the Sprint’s branch is rebased with the new code base from Production, thus insuring the hotfix continues to exist in next Sprint’s release. You should not only consider rebasing the current Sprint branch that is under development, but ALL open feature branches that have the potential to make it into Production. This should be treated by your development team and yourself as close to religious dogma as you can make it.

Figure 3

A final note to consider here, but not demonstrated with a diagram is what to do with feature branches or for that matter Sprint branches that never made it into Production and never will. It is a wasted effort to keep rebasing that which will never exist in Production. I would recommend locking and hiding or destroying these “orphaned” branches, so they are never used by accident.