Homologar é preciso!

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.

Compartilhe

Você pode gostar

pg_hba.conf

Introdução O arquivo pg_hba.conf (PostgreSQL Host-Based Authentication) é uma peça fundamental na configuração de segurança de qualquer instância PostgreSQL. Ele define as regras de autenticação

Tuning de SO (no Linux)

Introdução Tuning refere-se ao processo de ajustar e otimizar o desempenho de um sistema, software ou aplicação. A otimização do sistema operacional é uma etapa

Tipos de cargas dos bancos de dados

Introdução Cargas de dados referem-se aos diferentes tipos de operações e transações que um banco de dados deve processar. Essas cargas variam conforme o tipo

plugins premium WordPress