Nous avons vu précédemment comment migrer SonarQube depuis Tomcat en service Windows et comment utiliser SonarQube en service Windows avec Jenkins sous Tomcat,

J’ai utilisé la même version 3.5.1 pour effectuer cette migration depuis Tomcat vers un service Windows, et comme celle-ci est déjà ancienne, ceci sera l’occasion de réaliser un upgrade de versions et de mettre à jour notre environnement SonarQube avec nos différents plugins.

Nous allons consacrer deux articles à cette opération, dont ce premier afin de présenter les étapes préalables à notre upgrade. Ce sera également l’occasion de voir un backup Oracle.

Task list

Dans un premier temps, je vais d’abord planifier les différentes actions à réaliser. Non pas que cette opération soit compliquée, mais c’est l’occasion d’effectuer un état des lieux de notre environnement, et en particulier des évolutions au niveau des plugins. Un upgrade ne consiste pas uniquement à installer une nouvelle version de SonarQube mais également à mettre à jour nos plugins. Et j’aime bien savoir quelles sont les évolutions disponibles, s’il existe de nouvelles règles à tester, une nouvelle fonctionnalité à mettre en oeuvre, etc.

Enfin, lister les plugins à upgrader permet de garder une certaine traçabilité de notre environnement, et je vous conseille de faire de même, notamment si vous utilisez SonarQube dans un cadre professionnel. Une nouvelle règle ou la modification d’une règle existante dans vos analyses de code peut amener une hausse subite de défauts dans le tableau de bord SonarQube, sans que les développeurs comprennent la cause de cette dégradation soudaine de la qualité de leur application.

La première réaction est alors de mettre en doute la validité de vos analyses, et dans ce cas, mieux vaut être prêt à répondre qu’une nouvelle version de plugin a introduit une nouvelle règle à l’origine de ces nouveaux défauts. Garder un document avec les modifications apportées à votre environnement d’analyse permet de justifier ces évolutions.

Update Center

Je garde tous les courriers de la liste de mails SonarQube annonçant les nouvelles versions logicielles ou de plugins, mais il existe un moyen plus simple de connaïtre lesquels sont à jour ou non : l’Update Center.

Pour cela, nous allons nous connecter en Admin depuis le tableau de bord SonarQube.

Puis, nous rendre dans la page de l’Update Center en sélectionnant le menu :

‘Settings’ puis le sous-menu  ‘Configuration’.

Depuis cette page de configuration, nous choisissons le menu ‘Update Center’ afin d’afficher l’écran correspondant, avec ses différents onglets qui nous permettent de connaître :

• Les plugins installés.
• Les plugins non installés et disponibles á l’installation.
• Les plugins pour lesquels une nouvelle version est disponible.
• Toute(s) nouvelle(s) version(s) de SonarQube.

Et surtout, la liste des actions à effectuer afin de réaliser un upgrade de version SonarQube, depuis l’onglet ‘System Updates’ :

La mise à jour de mon environnement Sonar va donc consister en :
1.    Suppression de plugins obsolètes.
2.    Upgrade de version de plugins existants.
3.    Upgrade de version SonarQube.
4.    Upgrade (post-upgrade SonarQube) de plugins existants ou ajout de nouveaux plugins.

Nous allons en profiter également pour aller vérifier sur le site web de SonarSource la procédure d’upgrade mais aussi consulter les Release Notes (en bas de page).

Et comme conseillé dans cette page, effectuer un backup de notre environnement actuel, et en particulier de notre base de données Oracle.

Backup Oracle

Un backup Oracle se fait tout simplement depuis une fenètre DOS, avec une commande d’EXPort des données de la base. Un restore d’un schéma (ou de la base entière) s’effectuera avec une commande d’IMPort.

Attention cependant : ces commandes ont changé avec la version 10g d’Oracle. Il est encore possible d’utiliser les anciennes commandes EXP / IMP pour effectuer un backup / restore, mais il faut savoir que cette commande EXP ne gardera que les données … des tables avec des données. En d’autres termes, seules les tables contenant des enregistrements seront sauvegardées. Et si vous restaurez un schéma Sonar depuis un dump efffectué avec la commande EXP, SonarQube rencontrera une erreur puisque certaines tables (vides) seront ainsi manquantes.

Les commandes à utiliser afin d’éviter ce problème sont EXPDP et IMPDP. DP pour Data Pump (oui je sais, moi aussi le nom me fait sourire). Attention à nouveau : les dumps générés ne sont plus au même format. En d’autres termes, vous ne pouvez pas restaurer avec la commande IMPDP un dump créé avec la commande EXP.

Dernière chose : la syntaxe de ces commandes reste assez proche, sauf pour l’emplacement du fichier de dump. Comme nous pouvons le voir dans l’illustration suivante, nous allons indiquer en paramètres de la commande EXPDP :

• Le nom du user Oracle correspondant au schéma Sonar, avec son password et l’indication de la base de données, selon la syntaxe schéma/password@dbname, soit sonar/sonar@JPORA11 dans mon cas.
• Le nom du fichier dump qui résulte du backup.
• Le nom du fichier log de backup, qui permet de vérifier que celui-ci s’est bien déroulé.

Le log vous donnera également la liste des tables ‘exportées’, ce qui vous permettra de vérifier que les tables avec ‘0 enregistrements’ sont bien présentes dans le backup.

Par contre, et contrairement à l’ancienne commande EXP, le dump ne se trouve pas dans le répertoire depuis lequel nous avons lancé l’export, mais par défaut dans un répertoire ‘DPDUMP’ sous le répertoire d’installation de notre base de données, sous le répertoire d’installation de Oracle. J’aurais préféré décider où s’effectue le backup mais bon, une fois que nous savons où récupérer celui-ci… Il est possible de définir un autre répertoire par défaut, mais il faut écrire un script SQL pour changer ce paramètre, ou entrer manuellement les commandes SQL correspondantes. Un peu compliqué.

Bien. Nous en avons terminé avec les actions préalables à notre upgrade SonarQube. Que nous verrons dans notre prochain post.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.