Deploy tardio: um antipadrão no Release de Software

Assim como no texto sobre Logs, meu interesse neste assunto surge a partir de uma necessidade na minha rotina diária enquanto desenvolvedora.

Já percebeu como a proximidade do release* de um software pode ser tensa?

*Release: lançar sua aplicação ou sistema para produção
*Implantar: efetuar o deploy da sua aplicação em um ambiente específico que não o de desenvolvimento local

Lendo o Continuous Delivery, de Jez Humble, fui percebendo vários antipadrões que são comuns no Release de Software. Também fui reconhecendo vários erros que já cometi ou já vi sendo cometidos em projetos passados. No início da minha leitura percebi um (anti) padrão muito comum Release de qualquer Software, que é:

Implantar sua aplicação em um ambiente semelhante ao de produção somente depois que o desenvolvimento foi feito

Eu não estou falando de fazer check-in do seu código em um ambiente de controle de versão. O comum neste (anti) padrão é realizar a implantação de uma aplicação para um ambiente semelhante ao de produção somente quando a maior parte do desenvolvimento já foi feito. #QuemNunca?

O (anti) padrão é parecido com:

  • Ninguém se preocupou em ter um ambiente de pré-produção. Seja porque esse ambiente tem um alto custo ou simplesmente porque ninguém vê o valor de tê-lo.
  • Há pouca, ou nenhuma, colaboração do time de desenvolvimento com o time que de fato realiza a implantação da aplicação para produção (o time que faz o release).
  • Se as pessoas responsáveis por testar sua aplicação (devs, analistas de qualidade, etc) estavam envolvidas no processo de desenvolvimento, provavelmente esses testes foram feitos em máquinas de desenvolvimento.
  • Os ciclos de release e implantação são muito grandes. Existe muito tempo entre uma implantação e outra (ou entre um release e o próximo).
  • Fazer a implantação para um ambiente de staging vai ser a primeira vez que alguém que não é do time que desenvolveu a aplicação interage com sua aplicação.

Esse antipadrão pode levar a vários riscos de Entrega e Release de Software. As principais desvantagens que podem afetar o seu Release são:

  • Você não saberá como sua aplicação vai se comportar com as integrações num ambiente semelhante ao de produção. Se sua aplicação deve se integrar a outros serviços, o risco de encontrar integration hell são enormes e você pode atrasar sua entrega.
  • Quanto mais tardia a implantação para ambientes que não são o desenvolvimento, menor o seu controle em como sua aplicação está se comportando com as configurações em ambientes mais realistas.
  • O time de desenvolvimento vai precisar fazer muitas suposições de como a aplicação vai se comportar quando estiver num ambiente real e integrado. O que, fatalmente, levará a erros após implantação e release.

Como evitar esse antipadrão?

A resposta agora parece bem óbvia. Simplesmente fazer o contrário do antipadrão?

Assim como o Continuous Delivery fala, é necessário incorporar ao processo de desenvolvimento: atividades de testes e sua automação, implantação para ambientes intermediários e Release. Ao tornar essa atividades parte da rotina do processo de desenvolvimento, quando chegar a hora do Release para produção, vários dos problemas que poderiam acontecer provavelmente já foram encontrados em etapas anteriores de desenvolvimento. Dessa forma, o time começa a economizar tempo (e dinheiro!).

Como eu posso incorporar essas atividades no meu time? Quais as metodologias? Quais processos já foram validados? Isso é assunto para outra conversa :)

Você já enfrentou esse problema durante a implementação dos seus sistemas e aplicações? Que outras características você adicionaria a esse Antipadrão?

Agradeço comentários e feedback. Até a próxima!