Migration from the old 5.6 to the new 6.7+ branching model

branches
sonarqube
guide

(Alexandre Frigout) #1

In the former model, a branch was considered as a separate project in itself by SonarQube. We should see two different entries into the project keys for the so-called master and for a branch.

Since SonarQube 6.7, branches are handled in a different way by SonarQube and we defined two different kind of branches:

More explanations about branches and branch analysis can be found here.

Coming to the migration strategy from 5.6 old-style to 6.7 new-style branches, we recommend the following for these two kind of branches.

Short living branches

These branches, typically used to develop individual features, are intended to live for a brief period of time then be merged back to the master or another long-lived branch. Given their short life-span, they are probably low-value candidates for migration anyway.
We then recommend to simply analyse short-lived branches on the 6.7+ instance using the sonar.branch.name feature.

Long living branches

These branches, typically maintenance or customer-specific branches, are intended to live for much longer, so SonarQube 6.7 and above versions handle them much more like a classic SonarQube “project”: they have their own project home page, leak period etc.
Here, the migration strategy we recommend is slightly different: essentially we suggest to run a new long-lived branch analysis on the branch and compare the results with the old 5.6-style branch project.
Then, according to the results with respect to the expectations, decide for each project or group of projects which path is valuable to take forward.

As explained here, when performing the first analysis of a long-lived branch, SonarQube takes all the issues from its target and copies them to the long-lived branch, including assignee, comments, resolution status, severity, creation date, etc. so that we can align and reconcile them for later.
This means that anything marked as a False Positive on the master, for example, would also be marked as a False Positive on the long-lived branch, this is an important improvement with respect to SonarQube 5.6 branching.
So in fact, the analysis we get using sonar.branch.name may be an improvement on the old sonar.branch analysis: better alignment of issues, etc.

What is lost with this technique is any history from the old 5.6-style project, this is why we suggest initially keeping the old branch project to look at the difference between it and the new sonar.branch.name analysis.
Old-style branches are still supported in SonarQube 6.7, then if a couple of branch projects are worth keeping for the issues history it is possible.

To wrap up

Our general recommendations to achieve this migration are then:

  • Short-lived branches: no migration necessary; simply analyse as a short-lived branch on SonarQube 6.7 or later version.
  • Long-lived branches: test an initial sonar.branch.name analysis on 6.7 or later and compare to the existing 5.6-style branch project to determine if the history in the old project is worth preserving.
  • Overall: lots of experimentation on a Test environment before rolling out to Production.

Sonarsource Support Team