Conheço muita gente que está acostumada a usar controle de versões, bug tracking e outras ferramentas importantes no desenvolviemnto de aplicações. Mas quando o assunto é banco de dados, poucos estão dispostos a investir em vários servidores de bancos de dados distintos. A situação ideal é ter

• Um servidor em produção
• Um servidor de homologação
• Um servodor de testes

Mas a questão é… para que investir num servidor de banco de dados de homologação?

Bom… a realidade é que o processo de desenvolvimento só adquire um estatus suficiente para entrar em produção, após a homologação, e este não pode ser feito no ambiente de testes. Vejamos as diferenças:

No servidor de testes, você pode iniciar o desenvolvimento de uma aplicação, a partir do zero, com dados completamente fictícios e pequenos volumes. Em geral, o servidor de testes costuma ter menor capacidade de armazenamento e processamento. O DBA costuma dar um pouco mais de liberdade para o desenvolvedor neste servidor. A principal preocupação aqui é com o modelo de dados. O trabalho do AD aqui é fundamental, sendo modelo lógico o principal alvo de alterações. É na base de testes que os testes de componente ocorrem.

No servidor de homologação, os desenvolvedores perdem os seus direitos e entra em ação o trabalho do DBA. Os dados da base de produção devem ser carregados na sua totalidade (se a aplicação já estiver em produção). A conversão do modelo de dados deve ser testada. Quando a aplicação for completamente nova… um bom gerador de dados é importante. Deve-se realizar uma carga com volume compatível com o esperado após alguns anos de operação. O servidor de homologação, precisa ter uma capacidade de armazenamento semelhante a do servidor de produção, além da capacidade de processamento. Mais que isso, é importante que a arquitetura física e lógica seja o mais semelhante possível ao do servidor de produção.

É no servidor de homologação que os testes da aplicação ocorrem. Os testes de desempenho vão permitir que um bom DBA faça ajustes na estrutura física de armazenamento e sugerir ajustes no SQL da aplicação. Muitas pessoas desprezam estes testes e depois de um par de anos.. descobre que a aplicação foi mal projetada e começa apresentar graves problemas. Consertar isso depois de dois anos é realmente muito difícil. A chance de você perder o cliente ou gastar muito dinheiro para resolver o problema é grande.

Artigo publicado em quinta-feira, 14 de junho de 2007 às 10:06 e arquivado em Banco de Dados.Comentários a este artigo podem ser verificados através do feed RSS 2.0. Você pode deixar um comentário ou fazer um trackback de seu próprio site.