Hemos visto anteriormente cómo migrar SonarQube de Tomcat en un servicio Windows y cómo utilizar este servicio SonarQube con Jenkins en Tomcat o en servicio Windows también.

He utilizado una versión 3.5.1 para realizar esta migración desde Tomcat hacia un servicio de Windows. Esta versión ya es un poco vieja, pues es una oportunidad para hacer un upgrade y actualizar nuestro entorno SonarQube y nuestros distintos plugins.

Vamos a dedicar dos artículos a esta operación, y en este primero, vamos a presentar las etapas previas a nuestro upgrade. También será la oportunidad de realizar una copia de seguridad de Oracle.

Task list

En primer lugar, voy a planificar las diferentes acciones que realizar. Esta operación no es complicada, pero es una oportunidad para hacer un inventario de nuestro entorno y de las evoluciones de los plugins. La actualización no es sólo la instalación de una nueva versión de SonarQube sino también un upgrade de plugins. Y me gustaría saber qué cambios están disponibles, si hay nuevas reglas que  probar, una nueva característica que implementar, una nueva funcionalidad que me podría interesar.

Por último, hacer una lista de los plugins que actualizar permite mantiener algún rastro de nuestro entorno, y te sugiero que hagas lo mismo, sobre todo si utilizas SonarQube en un entorno profesional. Una nueva regla o la modificación de una regla existente puede crear un aumento de los defectos en un análisis de código sin que los desarrolladores puedan entender la causa de este súbito deterioro de la calidad de su aplicación.

La primera reacción es poner en duda la validez de vuestros análisis, y en este caso, es mejor estar preparados para explicar que nueva versión del plugin ha introducido cual nueva norma al origen de estos nuevos defectos. Mantener un documento con los cambios en tu entorno permite justificar estos cambios.

Update Center

Tengo todos los correos de la lista de mails SonarQube anunciando una nueva versión del software o de plugins, pero hay una manera más fácil de saber que es up-to-date o no: el Update Center.

Por eso, vamos a conectarnos como Admin en el dashboard de SonarQube.

Luego vamos a la página del Update Center y seleccionamos el menú:

‘Settings’ y el sub-menú ‘Configuration’.

En esta pagina de configuración, elegimos el menú ‘Update Center’ para mostrar la pantalla correspondiente, con pestañas que nos permiten conocer:

• Los plugins instalados.
• Los plugins no instalados pero disponibles, que podemos instalar.
• Los plugins con una nueva versión disponible.
• Toda(s) nueva(s) versione(s) de SonarQube.

Y lo más importante, la lista de acciones para realizar un upgrade de versión de SonarQube desde la pestaña ‘System Updates’:

Por tanto, la actualización de mi entorno Sonar será:
1. Quitar los plugins obsoletos.
2. Actualizar la versión de los plugins existentes.
3. Actualizar la versión de SonarQube.
4. Upgrade (posterior a la actualización de SonarQube) de plugins o añadir nuevos plugins.

Aprovecharemos también para comprobar en el sitio web de SonarSource el procedimiento de upgrade y consultar las Release Notes (al final de la pagina).

Y tal como se aconseja en esta página, vamos a hacer una copia de seguridad del esquema Sonar en la base de datos Oracle.

Backup Oracle

Lo más sencillo para realizar una copia de seguridad con Oracle es desde una ventana DOS con un comando para EXPortar los datos de la base de datos. Restaurar un esquema (o toda la base de datos) se hace con un comando de IMPort.

Pero cuidado : estos comandos han cambiado con el Oracle 10g. Todavía es posible utilizar las antiguas clausulas EXP / IMP para realizar un backup / restore, pero tengas en cuenta que este comando EXP guarda los datos de … tablas con datos. En otras palabras, sólo se guardarán las tablas que contienen registros. Y si se restaura un esquema de Sonar de un dump realizado con el comando EXP, encontrarás un error con SonarQube, ya que no podrás contar con algunas tablas vacias.

Los comandos que utilizar para evitar este problema son EXPDP y IMPDP. DP significa Data Pump (sí, lo sé, a mi también el nombre me hace sonreír). Cuidado de nuevo: los dumps no son del mismo formato. En otras palabras, no se puede restaurar con el comando IMPDP un dump realizado con el comando EXP.

La sintaxis de estos comandos es bastante similar, excepto para la ubicación del archivo dump. Como podemos ver en la siguiente ilustración, los parámetros que indicamos son:

• El nombre del usuario Oracle para el esquema Sonar, con su password y la indicación de la base de datos, respectando la sintaxis esquema/password@dbname, sonar/sonar@JPORA11 en mi caso.
• El nombre del fichero dump de backup.
• El nombre del fichero log de backup, que permite comprobar que todo se paso bien.

El log te dará también la lista de las tablas ‘exportadas’, que te permitirá comprobar que las tablas con ‘0 registros’ están presentes en la copia de seguridad. O si tienes un problema con SonarQube despuès de restaurar este dump, al menos no vendrá del backup.

Pero hay una diferencia con el antiguo comando EXP, el dump no se encuentra en el directorio donde hemos lanzado el backup, pero por defecto, se genera en el directorio ‘DPDUMP’ bajo el directorio de instalación de la base de datos bajo el directorio de instalación de Oracle. Hubiera preferido poder decidir dónde colocar la copia de seguridad, pero bueno, una vez que sabemos dónde conseguirla … Es posible configurar un directorio predeterminado, pero hay que escribir un script SQL para cambiar esta configuración, o hacerlo manualmente con los comandos SQL correspondientes. Un poco complicado.

Bueno. Ya hemos terminado con nuestras acciones previas para actualizar SonarQube. Lo que veremos en nuestro próximo post.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.