ii. Prerequisite

Prerequisite

Sonar Version

This tool works for both for version 3.6+ (tested on 3.7.2) (where violations & reviews become issues 3.6 upgrade note) and earlier version (tested on 3.4.1). For version earlier than 3.6, exception handling is not done and resume functionality not available in case of issue.

Target Database

This tool is developed & tested for target sonar DB as postgresql but ideally with correct JDBC driver, it can work with any database, however, due to different way of handling id generator by different driver, some code change might require to work with other target DB e.g oracle. There is no dependency on source sonar DB and it can be any as long as you make its driver available in classpath.

We learn in earlier section, static data which is displayed on sonar dashboard can be generated any points of time with same code. So target of the tool is not to migrate issues (violations) itself. This tool targets to migrate manual data (issue history) associated with issue (violations). In order to migrate data for any sonar issue, we need to have same issue raised at both sonar instance with same rule and on same line.

In order to achieve this, we have 2 ways

With Command Line

1. Do maven build

   	mvn clean install -Poracle -Dmaven.test.skip=true
   

Not necessary to run install goal, you can just run compile goal also as we just need to make sure code compiles. JUnit result can anyway generated again on new server so no need to run test phase too.

2. Run sonar analysis for old server

   	mvn sonar:sonar -Dsonar.profile=<xyz Profile> -Dsonar.branch=<xyz Branch> -Dsonar.forceAnalysis=true
      -Dsonar.jdbc.url=<sonar 1 jdbc url> -Dsonar.jdbc.driver= <sonar 1 jdbc driver> -Dsonar.jdbc.username=<sonar 1 jdbc username> 
      -Dsonar.jdbc.password=<sonar 1 jdbc password> -Dsonar.host.url=<sonar 1 jdbc host url>
   

3. Run sonar analysis for new server (on same built code)

          mvn sonar:sonar -Dsonar.profile=<xyz Profile> -Dsonar.branch=<xyz Branch> -Dsonar.forceAnalysis=true
        -Dsonar.jdbc.url=<sonar 2 jdbc url> -Dsonar.jdbc.driver= <sonar 2 jdbc driver> -Dsonar.jdbc.username=<sonar 2 jdbc username>
         -Dsonar.jdbc.password=<sonar 2 jdbc password> -Dsonar.host.url=<sonar 2 jdbc host url>
   

With Jenkins Job

In Jenkins, Sonar is added as Post-build Action. However, due to restriction at Jenkins, you can't add 2 sonar under this section. So we need to use work around.

1. Use one sonar server (preferably new server) as post build action.
2. Add sonar:sonar goal as part of normal maven goals and add same argument value as you used as part of post-build configuration (Branch name, MAVEN_OPTS and Additional properties) + all old sonar server specific details (e.g. db username,host etc.). This will effectively prepare same command which is executed via post-build action but for report on old sonar server.


After changes, goals and options will have like below. Here 2nd & 3rd lines are additional thing we added in normal maven goals and options. 4th & 5th lines are for arguments we took from Sonar post-build configuration.

      mvn clean install -Poracle -Dmaven.test.skip=true 
      sonar:sonar  -Dsonar.forceAnalysis=true -Dsonar.jdbc.url=<sonar 2 jdbc url> -Dsonar.jdbc.driver= <sonar 2 jdbc driver>
     -Dsonar.jdbc.username=<sonar 2 jdbc username> -Dsonar.jdbc.password=<sonar 2 jdbc password> -Dsonar.host.url=<sonar 2 jdbc host url>
     -Dsonar.profile=<xyz Profile> -Dsonar.branch=<xyz Branch> -DMAVEN_OPTS="-Xms512M -Xmx1024M" 
     -Dsonar.exclusions= "<some exclusions>" 



Now when you run this job, it will first execute normal maven build task and then run sonar analysis on old sonar server. After that with the same code it will again run sonar analysis on new sonar server as part of post-build action. This way we will be able to run sonar analysis on 2 different sonar server with same code as code checkout will happen just once in beginning of job. You don't need to worry if JUnit statistics are different due to 2 times sonar execution as correct statistic can be generated later again on new sonar instance (alternatively pass argument -Dsonar.dynamicAnalysis=reuseReports).

Verify data

Once we have sonar analysis report available on both the places, make sure that its same. Mainly comparing lines of code and total issues should be enough. Note that for old sonar report total issues would be issues you see on dashboard + false positive you see under reviews tab.

Old Sonar Server 

New Sonar Server 

If you find that lines of code and total number of issues are same then it means now you already have correct report available on new sonar server and you are ready for data migration.

Note that while you start with data migration, new analysis should not start on any sonar server which may potentially create differences between 2 reports.