O processo de deploy contínuo
Postado em 01. mar, 2010 por Guilherme Silveira em Agile
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?
Guilherme Silveira (Google+)
10 Respostas para “O processo de deploy contínuo”
Trackbacks/Pingbacks
-
-
março 9, 2010
[...] a requisitos não funcionais. Um exemplo é a instalação de um servidor de homologação e processo de homologação e deploy contínuo no estilo devops, fugindo do estilo tradicional, menos ágil, de operações. O que [...]
-
-
abril 20, 2010
[...] mais de dois anos, a Caelum tem feito um esforço sobre cortar diversos tipos de débitos técnicos, incluindo levar práticas ao extremo, como testes end-to-end em [...]
-
-
junho 29, 2010
[...] assunto de deploy contínuo, não trouxe nada de muito novo. O Guilherme Silveira, da Caelum, havia blogado em março e feito uma apresentação em maio sobre esse tema no evento Maré de Agilidade, em [...]
-
-
julho 11, 2010
[...] Total http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html http://blog.caelum.com.br/2010/03/01/o-processo-de-deploy-continuo/ [...]
-
-
novembro 10, 2010
[...] processo de build é o coração das práticas de engenharia ágil: é através dele que automatizamos todos os passos necessários para garantir a qualidade mínima [...]
-
-
dezembro 22, 2012
[...] Há bastante tempo aplicamos e escrevemos sobre integração contínua, uma das práticas mais importantes do desenvolvimento ágil. É também o assunto de um curso online da Caelum que tem bastante procura. Através dela, é possível agilizar tarefas demoradas como a compilação de um projeto e a execução dos seus testes automatizados. Com um servidor de integração contínua bem configurado, essas tarefas são executadas a cada mudança no repositório de código e, em caso de erros de compilação ou falhas nos testes automatizados, todos os desenvolvedores são alertados rapidamente. Dessa forma, se o servidor de integração não aponta problemas no projeto, a equipe tem a segurança de que as mudanças no código estão de acordo com a bateria de testes. É também um passo na direção do deploy contínuo. [...]
ASSINE NOSSO RSS
Rafael O. Marques
04. mar, 2010
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.
Fred Estrela
04. mar, 2010
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.
Gabriel
08. mar, 2010
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í.
Washington Botelho
09. mar, 2010
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.