Top Posts

Série Scrum Remoto: Adotando uma ferramenta online ideal para o

Continue lendo

Automatizando seu DB com FlyWay Plugin – MySql

Posted by camilolopes | Posted in BD, Java | Posted on 07-02-2014

1

Olá Pessoal,

No post de hoje vou mostrar para vocês como podemos automatizar a criação de um banco de dados usando o plugin flyway. Aqui na ITS temos usado o plugin para aumentar a produtividade e sempre manter a integridade dos ambientes.

Lets go…

O problema

Há várias ferramentas e formas de automatizar a criação das tabelas do banco com cenários já prontos ou até vazios.  Aqui na ITS, para os projetos Java temos usado o flyway, apesar de que testamos outras como o DBMaintain, mas optamos pelo plugin flyway, já que em termos de resultado final era semelhante ao dbmaintain, porém a curva de aprendizado e configuração  era mais rápida.  Para projetos Ruby, estamos vendo outra solução.

O problema que tínhamos aqui era a criação da base de dados para cada ambiente, desde local até ambiente de INT, DEV e PROD. A modelagem do banco pode mudar (e certamente vai) e quando isso acontece, o problema está feito. Como atualizar cada ambiente rapidamente?

Opção 1

Criar um dump do banco e rodar o .sql em cada ambiente manualmente.

Opção 2

Automatizar esse processo de update.

Nesse post vamos nos limitar apenas em como gerar a base de dados rapidamente. Em outro post veremos como atualizar outros ambientes através de uma ferramenta de build continuous como o Jenkins. 

A opção 1 funciona, mas não é a ideal, pois é preciso logar em cada ambiente e rodar o .sql. Isso consome tempo e é chato de fazer, ninguém gosta de fazer esse trabalho repetitivo. E se o banco durante o dia mudar 3 ou 4 vezes? Quantas vezes você vai executar a opção 1? Se você tem 3 ambientes para atualizar será preciso fazer isso 3 vezes a cada mudança. Péssimo, não? 

A opção 2

Você pode automatizar. Há ferramentas que ajudam a fazer isso usando um Servidor de Build como o Jenkins ou até como plugin maven.  Já usei o dbmaintain, mas analisando outras opções encontrei o flyway, até porque o desenvolvedor pode rodar o plugin local e se tiver o banco de dados rodando em segundos ele tem o ambiente local atualizado.

Configurando o FlyWay  via Maven

Antes de tudo você precisa ter um arquivo .sql que irá criar as tabelas e ele deve estar nessa estrutura: src/main/resources/db/migration

flywaysql

E o nome do arquivo tem que ser V1__QUALQUERNOME.sql

São 2 underscore. Se seu banco mudou você precisa ter um V2 e assim por diante. O flyway faz um tracking disso e salva em uma tabela schema_version. Se você tem mais de um ambiente, sugiro dar uma lida nesse post:

http://lwandersonmusings.blogspot.com/2012/07/using-maven-to-integrate-flyway.html

Vamos ver na prática um simples exemplo. Vou considerar que você já tem um projeto Maven

Step 1

Abra o pom e adicione:

 

 Step 2

Garanta que o banco foi inicializado.

Step 3

Garanta que o database exista, caso contrário o flyway não vai conseguir conectar.

flywaydatabase

Step 4

via command line (se preferir pode usar o Eclipse) digite o seguinte comando:

flywaycommandmigrate

Step 5

Veja o resultado:

flywaycommandmigrateresult

 

flywaytablecreated

Observe que as tabelas foram criadas. Tive que ocultar os nomes das tabelas. 

Simples não?

Alguns comandos básicos

 

Limpar o Database, ou seja, todas tables são apagadas.

 

Mostra quando o último script foi rodado e o status.

 

Faz a migração, ou melhor, executa o .sql em si.

Note: Você pode usar o recurso de profiles e ter diferentes execuções para o flyway.

O flyway tem se mostrado um plugin muito bom no dia a dia e atendendo aos requisitos que precisamos, sem falar que tem uma boa documentação e os posts no blog deles tem sido bem mão na massa. 

Abraços, see ya!! 

DBUnit com HSQLDB + Hibernate + maven

Posted by camilolopes | Posted in Agile/Scrum/TDD, BD, Java | Posted on 08-12-2012

0

Olá pessoal!

No post de hoje vamos ver como executar nossos unit tests usando o DBunit com HSQLDB em memória, tendo o Hibernate como framework de persistencia e usando o maven. por que isso tudo? Eu passei por uns problemas chatos de configuração que normalmente não temos quando fazemos testes de cada um desses recursos separados, mas, quando tive que colocar tudo na mesma panela, surgiram uns problemas mais chatos para nós, desenvolvedores, estou falando daquelas exceções de não achar o arquivo, exceções genéricas dos frameworks, que nos faz ficar horas e horas googlando, etc.

lets go..

O que vou considerar?

Que você já conhece Hibernate e conhece o DBunit, porém agora pretende rodar seus testes em um projeto do tipo maven e que você tem dois arquivos hibernate.cfg.xml, um para os testes e outro para a aplicação em si.

O problema

Tudo começou quando, ao executar meus testes, simplesmente recebi aquela velha mensagem: cannot open JDBC Connection. Eu disse “como assim? O hibernate.cfg.xml está lá”. Daí comecei a investigar. Um ponto eu já sabia e publiquei aqui nesse troubleshooting: o maven procura o hibernate.cfg.xml em src/main/resources. E para os testes? Ele procura em src/test/resources. Até parece lógico, mas errei aqui e não coloquei meu arquivo de hibernate.cfg.xml de teste nesse local. Porém, veio outro problema: eu tinha renomeado meu arquivo hibernate.cfg.xml para hibernateTest.cfg.xml. Por que? Simplesmente queria ter essa diferença. E deixava assim a configuração nos meus testes:

 protected IDatabaseConnection getConnection() throws Exception {

conn = new DatabaseConnection(new Configuration().configure(“hibernateTest.cfg.xml”)

.buildSettings().getConnectionProvider().getConnection());

return conn;

}

Simplesmente recebia:


 

Dai o que fiz?

Mudei o arquivo para hibernate.cfg.xml e rodei a aplicação e o resultado:

 

Isso me custou umas 3hrs do meu dia. Infelizmente não fui pesquisar porque com o nome diferente do hibernate o maven não encontrava o arquivo, somente com o nome default.

O arquivo do DBunitTest é o mesmo que vimos nos outros post da série, a única diferença é que temos um projeto do tipo “simple maven project”.

Hibernate.cfg.xml para o HSQLDB

<session-factory>

<property name=”hibernate.connection.driver_class”>org.hsqldb.jdbcDriver</property>

<property name=”hibernate.connection.url”>jdbc:hsqldb:mem:db</property>

<property name=”hibernate.connection.username”>sa</property>

<property name=”hibernate.dialect”>org.hibernate.dialect.HSQLDialect</property>

<property name=”hibernate.show_sql”>true</property>

<property name=”hibernate.hbm2ddl.auto”>create-drop</property>

<mapping class=”com.camilolopes.qa.model.dao.bean.Account”/>

</session-factory>

 

Configuração do pom.xml Adicione as dependencias abaixo:

<dependency>

<groupId>hsqldb</groupId>

<artifactId>hsqldb</artifactId>

<version>1.8.0.10</version>

</dependency>

<dependency>

<groupId>javassist</groupId>

<artifactId>javassist</artifactId>

<version>3.12.1.GA</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

<dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-core</artifactId>

<version>3.6.10.Final</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

<dependency>

<groupId>org.dbunit</groupId>

<artifactId>dbunit</artifactId>

<version>2.4.8</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

 

Crie um bean e um teste para persistir o objeto:

Bean

@Entity

@Table(name=”account”)

public class Account {

@Id

@GeneratedValue

@Column(name=”ID”)

private Long id;

@Column(length=20,name=”TYPE”)

private String type;

}

Test

A classe de test deverá estar assim, e omitir o que não mudou do outro arquivo, como a conexão e o load do .xml.

public DBUnitTest() {

try {

session = getSessionFactory().openSession();

getDataSet();

} catch (Exception e) {

e.getMessage();

}

}

public static SessionFactory getSessionFactory() {

sessionFactory = new Configuration().configure().buildSessionFactory();

return sessionFactory;

}

@Test

public void testSave(){

session.beginTransaction();

Account account = new Account();

account.setType(“USER”);

session.save(account);

}

Enfim, é isso ai. Caso precise rodar seus unit tests com maven + hibernate + hsqldb, sem ter dor de cabeça com arquivo de configuração, essa foi a solução que encontrei.

Abracos, see ya!!