Diferentes ambientes: Development, Testing, Staging e Production

Uma das práticas mais interessantes nessa “nova onda” de qualidade que está “encrostada” nas práticas agile de desenvolvimento de software, é o uso de diferentes ambientes para diferentes estágios do ciclo de vida de uma aplicação.

Com auxílio da virtualização, podemos implementar (sem dificuldades) estes ambientes em qualquer empresa que tenha como cultura entregar software de qualidade.

Development

Ter um ambiente isolado só seu, onde você possa codificar sem se preocupar com o resto da equipe. Essa é a premissa do ambiente de desenvolvimento.

Em Python, é muito simples construirmos um ambiente isolado em nossas máquinas, isolado até mesmo do nosso SO. Podemos codificar, testar, errar e corrigir, sem afetar diretamente os outros membros da equipe.

Onde eu trabalho atualmente, o ambiente de desenvolvimento é totalmente construído em uma máquina virtual, devido as fortes dependências entre ferramentas como Nagios e RRDTools.

Ao fim do dia (ou de uma feature), você pode “comitar” suas alterações para uma máquina central, comumente chamada de “Integration” (podendo ser o responsável por manter um servidor SVN ou um repositório central quando for um DVCS).

Antes de implantar o método descrito acima, o ambiente de desenvolvimento era um servidor compartilhado onde os membros da equipe trabalhavam simultaneamente (no mesmo ambiente). Funcionou e tenho certeza que funcionaria até hoje, mas acredito que ambientes isolados sejam mais organizados e seguros.

Testing

Quando você possui uma equipe de testes em seu projeto, nada melhor do que montar um servidor onde você possa por à prova as últimas modificações inseridas em sua aplicação.

Como eu nunca tive a oportunidade de trabalhar com pessoas dedicadas a testes, geralmente utilizo o próprio ambiente de staging para testes.

Embora testes unitários e de aceitação sejam amplamente executados em ambiente de desenvolvimento, quando o projeto ficar gigante, executar todos os testes do projeto a cada nova feature desenvolvida pode lhe consumir muito tempo. Neste caso é interessante você construir um servidor de integração contínua.

Na Uptime, trabalhávamos da seguinte maneira: Existia um servidor que era responsável apenas por clonar o repositório central e executar os testes automatizados. Quando um teste falhava, um membro da equipe era notificado, e ele designava alguém para resolver conflitos e problemas. O conceito é o mesmo apresentado no link acima, a exceção é que esse processo era uma tarefa agendada e executava em determinada hora do dia (e não diretamente a cada commit ou em um determinado momento do processo de integração).

Staging

O papel do ambiente de staging é ser o mais próximo da realidade, ou seja, ele deve ser uma réplica perfeita do ambiente de produção. Tratando-se de desenvolvimento Web, deve-se utilizar o mesmo serviço Web, o mesmo banco de dados, os mesmos módulos e plugins. Isso garantirá um deploy muito mais “suave” para o ambiente de produção.

No meu caso específico, utilizei o ambiente de staging para, além de testar a aplicação em um ambiente mais “real”, demonstrar as features para o cliente. Logo, ele tinha algo real, e com dados que faziam sentido, antes mesmo do projeto ir para o ar.

Ficou mais simples determinar se a aplicação soluciona o seu problema ou não.

Production

E finalmente, o ambiente de produção.

É neste ambiente que a sua aplicação ganha vida e enfrenta a dura realidade do mundo 🙂