Ambientes, salve os seus ou se extingüa!

“Meu pra que isso a gente edita e vai testando o código direto no domínio!” Eu me lembro dessa frase de um cara que eu estava treinando na minha última semana em um dos meus últimos empregos, esse tipo de afirmação sempre causa um arrepio na espinha, pior que quando eu ouço que a Jean Grey retornou da Morte.

A necessidade de um ambiente unificado de desenvolvimento, mas separado do de pré-produção e de produção é quase uma unanimidade entre os desenvolvedores com quem trabalhei, alguns negam a vezes que é necessário haver um ambiente de pré-produção. Mas como montar esses ambientes, que cuidados tomar?

Entendendo o que são os ambientes:

Os ambientes são o conjunto de recursos disponíveis e de comportamentos recomendados para a sua aplicação, explicando quando você começa um projeto você sabe que tipo de banco de dados deverá usar, bem como as requisições a serem feitos à webservices parceiros etc. Bem você realmente não quer ficar dando acesso público a uma aplicação que você está desenvolvendo para que os crackers disponíveis lhe rendam dores de cabeça.

Sem contar que nada mais chato que desenvolver na sua máquina pessoal, no meu caso hoje um netbook, e depois ter de readaptar os caminhos, ainda mais quando se está no Windows e se passa para um sistema UNIX, ou LINUX.  OU ter de preparar aquele processo maldito de sincronização de dados… ugh o coisa horrível.

Bem, mais quais são os ambientes que devemos utilizar? Eu trabalho normalmente com 3 ambientes:

1. Desenvolvimento;
2. Pré-Produção;
3. Produção.

O ambiente de Desenvolvimento:

É aqui aonde de fato as coisas acontecem, o ambiente de Desenvolvimento é o quintal do programador, depois que você faz o commit de sua aplicação, estou falando de SVN, ela deve ficar a disposição aqui. Nesse espaço normalmente eu deixo os programadores mexerem no php.ini, afinal esse aqui é o espaço da gente brincar, ligo o display_errors, mantenho o Xdebug e tal.

Uma coisa importante sobre o ambiente de desenvolvimento, sempre que você alterar, adicionar e retirar um reurso dele, você deve anotar isso e garantir que o mesmo ocorra em seus outros ambientes.

A aplicação tem sua infância aqui, é nessa hora que nós, desenvolvedores, a preparamos para a sua vida produtiva. Podemos corrigir seus defeitos sem culpa e sem pressa, relativamente, fazendo dela o melhor que ela pode ser.

Outra característica deste ambiente é que podemos enchê-lo de dados fakes.

O Ambiente de Pré-Produção

Depois que o escopo está cumprido, aparentemente, passamos ao teste de fogo, o ambiente de pré-produção, aqui antes de eu colocar meu sistema eu já faço a migração dos dados, e peço para que parte dos operadores do sistema o utilizem por aqui, e mantenho as tabelas do Banco de Dados através de triggers, normalmente eu mantenho o banco original e o de pré-produção no mesmo servidor, ou faço um slave do original no server de pré e sincronizo na base da Trigger. Mas voltando nesse ambiente o nosso sistema vai enfrentar o usuário, BIOS, assim podemos determinar quais os problemas mais comuns no dia a dia da operação do sistema, assim saber se devemos evitá-los programaticamente, ou simplesmente criar uma política para evitá-los.

Nesse ambiente 2 coisas são imprecindíveis. Primeiro aqui as coisas somente são instaladas se o forem em produção, bem como, todas as aplicações, configurações devem ser clones perfeitos do servidor de produção. Aqui também é aonde devemos fazer testes do tipo,forçar o congelamento do Banco de Dados, erros de memória do SO do servidor, essas coisas e ir criando o manual de recuperação de catástrofes, e obviamente testando os procedimentos de recuperação.

Ambiente de Produção

Esse aqui é aonde a coisa pega de verdade, normalmente se o programador fez seu trabalho direito, nessa parte o problema tá todinho na mão do sysadmin, uma coisa que sempre devemos prestar atenção aqui é display_errors OFF, nagios funcionando, ou qualquer outro sistema de monitoramento.  Qualquer atualização, instalação de outro aplicativo deve ser feito antes no ambiente de pré produção e testado até o dono do produto ficar satisfeito, e der isso por escrito.

Ainda me lembro que uma vez quando eu tinha um serviço rodando numa subversão do PHP 4, não lembro qual e migraram a aplicação parou de funcjonar do nada, ai eu vi que eles compilaram sem CuRL, pronto, você imagina um parser baseado em CuRL sem ela.

Bem galera por hoje foi só

No related posts.