O processo de deploy contínuo

Ao término do primeiro sprint, sua aplicação está andando muito bem e tem todas as histórias aprovadas enquanto no ambiente de testes. Passaremos então para a primeira tentativa de colocá-lo em produção/homologação, e logo descobre-se que o sistema não funciona corretamente nesse novo ambiente, e é gasto muita energia para adaptar diversos detalhes que já eram considerados “prontos”.

Após esse esforço, com a aplicação rodando em outra máquina diferente da de desenvolvimento, os clientes começam a utilizá-la e a quantidade de bugs específicos desse novo ambiente que aparecem sobrecarregam os desenvolvedores. O estranho de tudo isso é que o código original rodava na máquina do desenvolvedor sem problemas, inclusive com testes unitários e de aceite.

Em sistemas que não implementam testes end to end, mesmo que smoke tests e que não se planejam para deploys desde o começo do projeto, é comum encontrar um grande número de bugs no primeiro deploy de homologação, além de uma extrema dificuldade para realizar essa implantação inicial.

A equipe passa então a trabalhar para corrigir essa onda de bugs, fica incapaz de adicionar novas funcionalidades em um ritmo adequado e desanima rapidamente.

Enquanto o processo de deploy não for automatizado, cada nova tentativa de implantação é seguida por uma enchurrada de bugs novos, sempre com as mesmas consequências negativas.

A solução aqui é automatizar todo o processo de deploy desde o primeiro sprint, e para isso você precisa estruturar muito bem seu ambiente, de forma que ele seja perfeitamente replicável entre as máquinas de desenvolvimento, homologação e produção. Isso é bastante planfletado pelo movimento Devops.

Graças aos ciclos mais curtos de deploy, o cliente testa o seu software mais cedo e recebemos feedback mais rápido quanto a bugs existentes, portanto o número de bugs novos sai do zero muito mais cedo, diminuindo um possível susto.

Martin Fowler comentou recentemente sobre a estratégia de manter dois sistemas muito parecidos em paralelo e virar a chave de roteamento de um para o outro para efetuar a transição, processo que pode e deve ser automatizado por completo em aplicações de alta disponibilidade. Fábio Akita da Locaweb explica uma estratégia simples para deploy contínuo através do uso do git.

Tudo isso minimiza o acúmulo de bugs, resultando em um ritmo constante, mas menor, de aparição de problemas, inerentes a qualquer processo.

Com o deploy contínuo através de técnicas como a citada pelo Akita, cada commit terá não só suas baterias de testes rodados, mas entra em homologação. Os bugs aparecem mais cedo durante o desenvolvimento do projeto e o processo de deploy pode ser efetuado mais frequentemente.

Indo além, com um sistema blue-green, seu processo de deploy atinge um nível maior ainda de maturidade, com a possibilidade de um rollback robusto a qualquer instante.

Como você está tratando o seu deploy?

10 Comentários

  1. Rafael O. Marques 04/03/2010 at 15:53 #

    Está absolutamente certo quando você diz:

    “e logo descobre-se que o sistema não funciona corretamente nesse novo ambiente, e é gasto muita energia para adaptar diversos detalhes que já eram considerados “prontos””

    Mas nada melhor do que aprender com os próprios erros.

  2. Fred Estrela 04/03/2010 at 16:45 #

    Segundo paragrafo = meu carma. Quando o projeto começou, nem o cliente, nem a empresa tinha esse expertise. Agora estamos pagamos o preço, ou eu. Isso que da pegar o bonde (projeto) andando.

  3. Gabriel 08/03/2010 at 01:03 #

    Um outro fator que ajuda muito a diminuir problemas de deploy é se o desenvolvedor programasse em um ambiente local muito próximo com o de produćão, ou seja, mesmo sistema operacional, mesma versão de JVM, mesma versão de app server, mesmo encoding, mesmos paths e por aí vaí.

  4. Washington Botelho 09/03/2010 at 12:58 #

    Um deploy automatizado é de longe uma ótima opção para agilizar as coisas.

    Ainda estou em fase de adaptação da integração contínua com o deploy automatizado e todo o gerenciamento com o TeamCity. E isso esta me trazendo uma maior segurança nos projetos em produção.

    Parabéns pelo tópico.

Deixe uma resposta