We have seen previously how to migrate SonarQube from Tomcat to a Windows service and how to use SonarQube as a Windows service with Jenkins under Tomcat,

I did use the same release 3.5.1 to perform this migration from Tomcat to a Windows service, and as it is already old, this will be an opportunity to make an upgrade of Sonarqube and update our environment with new versions of plugins.

I will document this operation in two articles, including this first one to present the steps to prepare our upgrade. This will also be the opportunity to see how to do an Oracle backup.

Task list

At first, I will start planning the different actions to perform. Not that this operation is complicated , but it is an opportunity to make an inventory of our environment, and especially the plugins evolutions. An upgrade is not just an installation of a new version of SonarQube but also an update of our plugins. And I like to know what changes are available, if there are new rules to test, a new feature to implement, etc.

Also, to list the plugins to upgrade allows us to keep some trace of the evolutions of your environment, and I suggest you do the same, especially if you use SonarQube in a professional way, in your company. A new rule or the modification of an existing rule in your code analysis can trigger a surge of defects in the SonarQube dashboard, and your developers might not understand the cause of this sudden deterioration in the quality of their application.

Their first reaction could be to question the validity of your analysis, and in this case, you better be ready to explain which new version of a plugin has introduced which new rule at the origin of these new defects. Always good to keep a document to trace the changes in your environment.

Update Center

I keep all the mails from the SonarQube mailing list, that announce new release of the software or of a plugin, mais there is a simpler way to know which of the plugins you have installed are up-to-date or not: the Update Center.

First, we will connect into SonarQube as an Admin, from the SonarQube dashboard.

Then, we go in the Update Center page from the menu:

‘Settings’ and then the sub-menu ‘Configuration’.

From this configuration page, we choose the menu ‘Update Center’ in order to display the corresponding screen, with different tabs that show us:

• The installed plugins.
• The plugins not installed but available.
• The plugins for which a new version is available.
• Any new version of SonarQube.

And furthermore, the list of actions to realize the upgrade of SonarQube, in the tab ‘System Updates’ :

The update of my environment Sonar will therefore be:
1. Remove obsolete plugins.
2. Upgrade version of existing plugins.
3. Upgrade version SonarQube.
4. Upgrade (post-upgrade SonarQube) existing plugins or add new plugins.

I will also recommand that you check the upgrade procedure on the SonarSource website and to consult the Release Notes (at the bottom of the same page).

And as recommanded, we will first do a backup of our current environment, and especially of our Sonar user in the Oracle database.

Oracle backup

You can do an Oracle backup from a simple DOS window with a command to EXPort the data from the database. To restore a schema (or the entire database) will be realized with the IMPort command.

But beware: these commands have changed with the Oracle 10g release. It is still possible to use these old EXP / IMP clauses to perform backup / restore, but be aware that this does not keep the data from … tables without data. In other words, only tables containing records will be saved. And if you restore a Sonar schema from a dump realized with the EXP command, SonarQube will show an error, since some empty tables will probably be missing.

The commands to use to avoid this problem are EXPDP and IMPDP. DP means Data Pump (yes I know, this funny name makes me always laugh). Beware again: dumps are not generated in the same format, so you can not restore with the IMPDP command a dump created with the EXP command.

Last thing: the syntax of these commands is quite similar, except for the location of the dump file . As we can see in the following illustration, we will indicate the following parameters:

• The name of Oracle user corresponding to the Sonar schema Sonar, with its password, and the indication of the dabase, with the syntax schema/password@dbname, sonar/sonar@JPORA11 in my case.
• The name of the dump file, result of the backup.
• The name of the log file, to verify that the backup is correct.

The log will also give you a list of the ‘exported‘ tables, which will allow you to verify that the tables with ‘0 records‘ are present in the backup.

Now, and unlike the old EXP command, the dump is not in the directory from which we started the export, but located by default in a directory ‘DPDUMP‘ under the installation directory of our database under the installation directory of Oracle. I would have preferred to decide where to save  the backup but hey, once we know where to get it … It is possible to set a different default directory, but you need to write a SQL script to change this setting, or manually enter the corresponding SQL commands. A little complicated.

Good. We’re done with the actions prior to the SonarQube upgrade. This we will see in our next post.

This post is also available in Leer este articulo en castellano and Lire cet article en français.