Configurando o Banco de Dados do Sonar (Oracle, SQL Server e MySQL)

Configurando o Sonar

No post Meus primeiros passos com o Sonar aprendemos como instalar e configurar o servidor de inspeção contínua Sonar. Aprendemos como inspecionar uma aplicação e gerar indicadores de qualidade.

No exemplo utilizamos o banco H2 que vem embutido no Sonar, esse banco não aceita conexões remotas o que o torna inviável para utilizar no dia a dia. Mesmo se você for utilizá-lo no dia a dia, somente na sua máquina, vai notar que depois de alguns dias de inspeções o servidor vai ficar muito lento, essa lentidão é por causa do banco de dados e para tratar disso vamos precisar escolher uma instância de banco de dados definitiva.

O Sonar suporta diversos bancos de dados, como SQL Server, Oracle e MySQL, dentre outros. Nesse post vamos focar nesses 3 principais bancos de dados Oracle, SQL Server e MySQL e mostrar como configurar, passo a passo, o Sonar em cada um desses bancos.

Procedimento para Banco de Dados

Instalar o banco do dados do Sonar é bem simples e segue o mesmo procedimento tanto no Oracle, quanto no SQL Server. Eu realmente acredito que seja o mesmo procedimento para o MySQL, mas não testei ainda.

Primeiro, crie um schema de banco de dados vazio no SGBD (Sistema de Gerenciamento de Banco de Dados) desejado.

Segundo, configure um usuário com permissões de executar DDL (Data Definition Language) no schema criado.

Terceiro, configure o charset do banco de dados para "UTF-8" e a linguagem padrão (do banco e usuário) para "English" (Inglês).

Quarto, configure o arquivo ".\sonar-3.7.4\conf\sonar.properties".

Vamos configurar o usuário que criamos no segundo passo, para isso localize no arquivo a parte de credenciais, como está no exemplo abaixo e configure o usuário e senha.

#----- Credentials

# The schema must be created first.

sonar.jdbc.username: sonar

sonar.jdbc.password: sonar

Depois procure no arquivo a configuração para o banco H2 que configuramos no artigo de primeiros passos e comente a linha "sonar.jdbc.url" que está no exemplo abaixo:

#----- Embedded database H2

# Comment the following line to deactivate the default embedded database.

sonar.jdbc.url: jdbc:h2:tcp://localhost:9092/sonar

Para comentar a linha basta colocar o jogo da velha (#) ficando como o exemplo abaixo:

#sonar.jdbc.url: jdbc:h2:tcp://localhost:9092/sonar

Configurando o Oracle

Ainda com o arquivo sonar.properties aberto localize o trexo abaixo:

#----- Oracle 10g/11g

# To connect to Oracle database :

#

# - It's recommended to use the latest version of the JDBC driver (ojdbc6.jar).

#   Download it in http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html

# - Copy the driver to the directory extensions/jdbc-driver/oracle/

# - Comment the embedded database and uncomment the following line :

#sonar.jdbc.url:                            jdbc:oracle:thin:@localhost/XE

Vamos descomentar a linha sonar.jdbc.url e configurar o banco de dados, ficando como o exemplo abaixo:

sonar.jdbc.url: jdbc:oracle:thin:@localhost/XE

sonar.jdbc.url: jdbc:oracle:thin:@//servidor:1521/instância

Dica: A configuração thin para o Oracle dispensa a configuração do TNS, nela já são indicados servidor, porta e instância. Porém ainda é necessário que a máquina possua o Client do Oracle instalado e funcionando. Ao especificar a porta na configuração pode ser necessário incluir as duas barras "//", como no segundo exemplo.

Continuando a configurar o arquivo...

# Uncomment the following property if the Oracle account has permissions to access multiple schemas,

# for example sonar schemas with different versions. In that case, use the same property during project analysis

# (-Dsonar.jdbc.schema=<schema>)

# The schema is case-sensitive.

#sonar.jdbc.schema: sonar

Vamos descomentar e configurar o schema que criamos no primeiro passo.

sonar.jdbc.schema: sonarBD

Atenção: Para evitar dores de cabeça depois de criado o banco no Oracle, fique atento com o TableSpace, ao analisar projetos maiores, constantemente o Oracle pode cair apresentando erro de falta de espaço no TableSpace, depois do banco ter sido criado a primeira vez, é importante aumentar o valor default dele, se não me engano no Oracle 11G era de 10mb, recomendo que ela seja setado para auto incremento para não ter dores de cabeça, ou para o tamanho máximo que ele suporta, não lembro se era 2gb ou 4gb, caso o DBA da infraestrutura da sua empresa não permita o TableSpace auto incremental.

Pronto, nosso banco no Oracle foi configurado com sucesso. 

Configurando o SQL Server

Ainda com o arquivo sonar.properties aberto localize o trexo abaixo:

#----- Microsoft SQLServer

# The Jtds open source driver is available in extensions/jdbc-driver/mssql. More details on http://jtds.sourceforge.net

#sonar.jdbc.url:                            jdbc:jtds:sqlserver://localhost/sonar;SelectMethod=Cursor

Vamos descomentar a linha sonar.jdbc.url e configurar a instância que criamos no primeiro passo.

sonar.jdbc.url: jdbc:jtds:sqlserver://localhost/sonarBD;SelectMethod=Cursor

Para conectar no SQL Server em máquina remota utilize a linha abaixo:
sonar.jdbc.url: jdbc:jtds:sqlserver://servidor:porta/sonarBD;SelectMethod=Cursor

Atenção: O Sonar possui as seguinte limitações para o SQL Server: o provider de conexão para o SQL Server não suporta ainda o SQL Server 2014 (versão que vem junto do Visual Studio 2013); para conectar no banco ele deve estar configurado em named pipe, isso significa que seu banco deve estar registrado em um servidor com acesso remoto, mesmo para a configuração localhost.

Para conectar no SQL Server do Azure (o usuário precisa indicar o servidor):
sonar.jdbc.username=<username>@SERVER
sonar.jdbc.password=<password>
sonar.jdbc.url=jdbc:jtds:sqlserver://SERVER.database.windows.net:1433/DATABASE;ssl=require;SelectMethod=Cursor

Atenção: O SQL Server no Azure tem um problema de geração de script, onde será necessário gerar uma instância local, conectar o sonar nessa instância para gerar o script e depois fazer um deploy do seu banco para o Azure.

Pronto, nosso banco no SQL Server (local, remoto ou no Azure) foi configurado com sucesso.

Configurando o MySQL

Ainda com o arquivo sonar.properties aberto localize o trexo abaixo:

#----- MySQL 5.x
# Comment the embedded database and uncomment the following line to use MySQL
#sonar.jdbc.url:                            jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true

Vamos descomentar a linha sonar.jdbc.url e configurar nossa instância de banco.

sonar.jdbc.url: jdbc:mysql://localhost:3306/sonardev?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true

Pronto, nosso banco no MySQL foi configurado com sucesso.

Vamos testar?

Abra a pasta .\sonar-3.7.4\bin\windows-x86-32 e execute o arquivo StartSonar.bat

Ao conectar no banco de dados configurado, o Sonar vai configurar toda a estrutura do banco de dados e fazer a carga inicial de informações necessárias para sua execução, caso ele identifique que está mudando a versão do Sonar ele também fará todas as atualizações automaticamente.

Caso não apareçam problemas de configuração de banco ou restrições de infra estrutura, o console será mantido aberto informando que está ativo e monitorando a porta 9000. Pode ser que a atualização do banco de dados demore, mas depois que ele consegue conectar não tive problema nas instalações.

Serviço do Sonar inicializado

Depois ao acessar o dashboard será exibida a tela inicial do Sonar vazia sem nenhum projeto. Não se esqueça, suas medições anteriores ficaram no banco de dados H2.

Dashboard do Sonar inicializado pela primeira vez

Conclusões

Definir em qual banco vou instalar o Sonar vai depender do gosto ou necessidade do cliente. Se estiver fazendo isso em casa como eu fiz para testar, não pense duas vezes, o MySQL foi o mais simples e rápido para configurar, é impressionando como tudo funcionou de primeira, a instalação fiz com o MySQL 5.6 foi super tranquila e rápida, depois foi só criar o Schema para o Sonar que chamei de sonardev configurado para encode UTF-8 e depois criei o usuário "sonar" tudo isso auxiliado pela ferramenta MySQL Workbench.

Para o Oracle ou SQL Server se sua empresa tiver disponível, use e abuse, a performance do banco no servidor é muito superior a instalação que vai ficar na máquina. Não quero menosprezar o MySQL que eu gostei muito, mas não o recomendaria para um servidor de produção do Sonar pois ainda desconheço os problemas que ele pode apresentar, mas sei que a taxa de crescimento para o banco é muito alta, a cada projeto incluído, principalmente projetos grandes, vai demandar muito da base de dados. Acredite ela cresce vertiginosamente. 

O Sonar não guarda só os resultados dos indicadores no portal, mas também todo o seu código fonte. Quando você for analisar as violações geradas pelo Sonar, ele vai te mostrar o seu código fonte e dizer, encontrei essa violação nessa linha, que tem esse comando e para corrigir faça isso. É simples para nós usuários do dashboard, mas é uma análise muito complexa por parte da ferramenta. Todas as visões baseadas no código fonte poderão ser mapeadas pelo Sonar diretamente no fonte, como Cobertura de Testes Unitários, código duplicado, métodos públicos sem comentários, enfim, isso tudo é para destacar como a base de dados é importante e o quanto ela vai crecer.

Confesso que fiquei um bocado desiludido com as limitações do Sonar no SQL Server, espero que com atualizações isso simplifique, mas hoje tá muito complicado, levei dias para configurar uma estrutura de teste em minha máquina.

Espero que tenham se divertido tanto quanto eu, pois foi um post bem complicado e desafiador.

Um grande abraço a todos e até a próxima.

Atenciosamente,
Erick Ferreira Marques da Silva