BT

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.

Avalie esse artigo

Relevância
Estilo/Redação

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
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.