Many organizations transition to short lived feature branches and employ practices like continuous integration/delivery. To work in practice, those feature branches have to be kept short lived. By applying behavioral code analysis, we’re able to visualize the branching activity, measure lead times, and even predict the delivery risk of individual branches. The resulting information may highlight bottlenecks in our process or development workflows, and also gives us early warnings so that we can prevent future problems. Follow along and see how it’s done.

Measure Lead Times

CodeScene is a behavioral code analysis tool that analyses patterns in version-control data. Recently, CodeScene introduced a new suite of analyses that measure branching activity as shown in the next figure.

An overview of the branch measures.

By default, CodeScene calculates statistics for all branches that have been worked on during the past two months. This gives us a chance to ensure that we stick to a short development duration. As you see, we also get a separate measure of the time it takes from the last commit until the branch is merged.

In the preceding figure, that average lead time to merge is 13 hours, which is definitely too long. This happens frequently because practices like code reviews tend to become bottlenecks. The consequences is that a developer finishes the work on a feature, move on to something new since we learn fast that it will take time to get feedback, and then has to context switch back to address potential code review findings. That’s expensive.

Such process loss can be detected automatically, and you see an example on an early warning in the preceding figure. Here’s how it works: since CodeScene analyses your behavior as an organization, the algorithms know what your typical branching patterns look like. As soon as the tool detects branches that deviates from those patterns, it raises a warning. If that happens, there are several things you can do:

Re-plan the scope: Sometimes it’s just too much work in a single feature. Identifying a smaller feature set that you can deliver faster is one way to shorten the lead times and minimize risk.

Prioritize verification activities: Use the early warning to focus extra code reviews and tests on the highlighted branches.

Long lived branches are at odds with continuous integration. They also increase the risk for merge conflicts and unexpected feature interactions, so use the early warnings above to act on time and as feedback to your planning.

Predict Delivery Risks

The detailed analysis provides more information as shown in the next figure.

A detailed analysis of the work on each branch.

The detailed metrics let you identify early signs of trouble such as branches that become congested by attracting contributions for several different authors. For example, you see that one of the branches in the preceding figure has contributions from 5 different developers. That cell is highlighted to show that this is another deviation from how you typically work on branches. Often, this happens because the scope of the branch is too large, and the classic example is a task along the lines of “refactor our most central part of the code”.

The most interesting column is the Delivery Risk value. CodeScene uses a machine learning algorithm that is trained to detect technical risks while weighting in the social side of code such as the experience of the developer doing the changes.

Use this information to plan preventive measures such as extra code reviews and tests. You can also setup a separate CodeScene analysis and just focus on the work being done on the branch. In extreme cases you may chose to postpone the merge of such high risk branches if you’re close to a critical deadline.