BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Implantação Contínua: Mais fácil falar do que fazer

por Vikas Hazrati , traduzido por Paulo Rebelo em 26 Mai 2011 |

A implantação contínua (continuous deployment) é frequentemente descrita como uma técnica Agile ou Lean, em que todo o código escrito para as aplicações é imediatamente implantado em produção. Há muitos benefícios dessa técnica, incluindo reduções na duração do ciclo de desenvolvimento/implantação e no tempo para disponibilização de correções e novas funcionalidades. Mas é mesmo tão fácil quanto parece?

Jim Bird escreveu que a maioria das mudanças citadas quando se fala da implantação contínua são triviais, como pequenos ajustes, melhorias cosméticas e correções de pequenos bugs. Qualquer coisa maior que isso requer uma análise mais detalhada e uma abordagem mais cuidadosa.

De acordo com Jim,

Alterações de esquema de banco não podem ser feitas de forma contínua. Mudanças funcionais maiores não podem e não devem ser feitas continuamente, mesmo com lançamentos "no escuro" [dark launching: lançar uma nova funcionalidade para um determinado número de usuários]. O site Etsy, por exemplo (uma das empresas usadas como uma vitrine para a implantação contínua), não implanta continuamente funcionalidades maiores voltadas ao público externo. A equipe do Etsy leva tempo para projetar, testar, analisar e planejar as mudanças com as equipes de operações, suporte ao cliente e gestão do produto – como acontece em qualquer organização sensata.

Jo Liss mencionou que o verdadeiro desafio com a implantação contínua é o custo diferente de zero para a reversão de mudanças. De acordo com Jo, para a integração contínua, o limite de quantas vezes se faz a integração é essencialmente técnico. Mas esse não é o caso com a implantação contínua, em que o custo de reverter uma mudança pode ser enorme.

Depois de ter sido feita a implantação para um site em produção, com usuários e dados valiosos, a reversão se torna cara, porque pode ser necessário fazer coisas como:

  • Migrar o banco de dados de volta para o esquema e as convenções anteriores
  • Pensar sobre o que aconteceria com os usuários que estão usando seu site naquele momento, com a aplicação sendo alterada debaixo dos seus pés (e podendo ocorrer a quebra de links e falhas em requisições Ajax).
  • Se o problema for um bug em vez de apenas uma decisão que se gostaria de reverter, pode ser preciso até mesmo o envio de emails aos usuários afetados pelo problema, ou lidar com chamados de suporte.

Da forma similar, Eric Ries indicou que um dos maiores desafios com a implantação contínua é a necessidade de estar permanentemente preparado para gerar uma release.

Por um lado, o tempo de resposta aos usuários é o menor possível; por outro lado essa situação [de prontidão eterna] é assustadora. Quando se faz lançamentos escalonados, o tempo entre eles traz uma rede de segurança (talvez um pouco ilusória). Há também o alívio em dividir a responsabilidade dos testes com o time de garantia de qualidade (QA).

Então, o que fazer para uma equipe obter os benefícios da implantação contínua?

Eric sugeriu o seguinte

  • Não inclua funcionalidades sem critério; desenvolva em resposta a demandas dos clientes
  • Codifique em pequenos lotes
  • Prefira testes funcionais a testes unitários, sempre que possível
  • Implemente alertas e monitoramento, tanto em nível de ambiente como de aplicação
  • Tolere erros inesperados apenas uma vez e corrija-os imediatamente

Jo recomendou enviar uma menor quantidade de commits para o servidor. Segundo ele, um atraso razoável para a implantação fica entre cinco horas e dois dias.

Se a equipe conseguir resistir à tentação de fazer a implantação imediatamente para produção, será possível evitar a maioria daquelas mudanças desagradáveis que você gostaria de não ter colocado em produção – isso com apenas uma pequena perda de feedbacks dos usuários.

Isso não quer dizer que a implantação contínua não é possível. Muitas empresas como Etsy, Heyo , IMVU e Atlassian, realizam a implantação contínua e, alegam fazê-la de forma eficaz.

Como Jim resumiu,

Há muito o que se aprender com a Implantação Contínua – por exemplo, como otimizar e simplificar a implantação e o lançamento de releases, e como reduzir riscos quebrando o trabalho em partes cada vez menores, tudo isso aliado ao monitoramento de operações e métricas. Mas não é o "Santo Graal do DevOps", ou pelo menos não deveria ser.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT