Diego Pacheco Tech blog

No post anterior comentei sobre a importância das práticas da engenharia como refactoring e versionamento aplicados ao Banco de Dados. Neste post vou mostrar como usar o Liquibase na prática com Apache Maven 2. A utilização em conjunto com Maven 2 é muito produtiva por dois fatores, o primeiro é que você pode criar um projeto Java no eclipse e utilizar o seu plugin de SCM sendo do CVS ou Subversion para versionar o projeto. O Segundo motivo é você pode colocar este projeto no seu servidor de build continuo e tendo assim as mudanças do desenvolvimento e banco acontecendo de forma igual e no mesmo momento. A Estrutura básica do Projeto Você poderia estruturar o projeto de várias formas, no site do liquibase existem algumas boas práticas de como estruturas os conjuntos de mudanças. Vamos a estrutura do projeto que criei: src/main/resources/ changelogs src/main/resources/ database-conf src/main/resources/ sql src/main/resources/ start-script pom.xml No arquivo pom.xml que f...

Faz tempo que o banco de dados deixou de ser um mero repositório. Hoje em dia os bancos de dados tem muito mais do que um mero repositório. Muitas aplicações tem diversos pontos em banco de dados, quando a maior parte de aplicação já não esta no banco. Quando olhamos para o desenvolvimento de software nos dias de hoje podemos perceber a utilização de diversas práticas e métodos da engenharia como Integração Continua, Sandboxes, Testes, Versionamento, Refactoring e muito mais. Mas e o banco de dados? Na maioria das vezes não utiliza estas práticas. A não utilização das práticas de desenvolvimento junto ao banco de dados tem motivos, dentre eles saliente a própria questão cultural. Em muitas empresas a equipe é dividia em desenvolvimento e banco de dados, logo que mexe com Java, .NET, Delphi ou qualquer linguagem por exemplo não é do mesmo grupo das pessoas que lidam com o banco. Outro fator é o paradigma, muitas vezes as equipes responsáveis pelo banco de dados estão atreladas a um pa...

Os requisitos não vieram de hoje, a sua necessidade já foi confirmada a muito tempo, mas ainda é comum ver empresas que falam aos 4 ventos que trabalham com requisitos e na verdade não sabem diferenciar um requisito de uma Constraint . Neste post vou falar mais de requisitos, dizendo o que são e o que não são requisitos, bem como qual a relação deles com as Constraints, pretendo falar um pouco mais dos tipos de requisitos e quanto tempo devemos gastar com requisitos. O Que é um Requisito? Um requisito tem que atender a duas premissas básicas, se você não atender a essas duas premissas, logo você não tem um requisito. Vamos então: Condição ou capacidade necessitada pelo usuário para realizar algum objetivo ou resolver algum problema. E o mais importante Desejado . O usuário tem que poder perceber, ou seja, Observado Externamente . Se não satisfaz esses itens acima, não é um requisito, infelizmente muitos analistas nem sabem o que é isso. Muitos viram do velho modelo em que o analista d...