Além da Integração Contínua: Implantação Contínua

Postado por Chris Sims , traduzido por Paulo R. C. Siqueira em 12 Mar 2009

Seções

Processos e Práticas,

Operações e Infraestrutura

Tópicos

Agile ,

Implantação / Datacenter

Tags

Deployment ,

Integração Contínua

O mais cedo uma funcionalidade entra em produção, mais cedo ela começa a gerar valor. O mais rápido um sistema puder ser alterado em resposta a feedback do usuário, mais fácil é manter o usuário feliz. Timothy Fitz e Joe Ludwig recentemente publicaram artigos que descrevem implementações práticas de implantação contínua, um processo que reduz o ciclo de releases de semanas para minutos.

O primeiro artigo de Timothy examinou o impacto que implantação contínua poderia ter no custo da correção de bugs. O quanto maior o tempo entre quando um erro é introduzido no sistema, e quando ele é encontrado, mais difícil e caro será corrigir o bug. Se o engenheiro vê o erro logo após tê-lo digitado, o custo do bug é essencialmente zero. Se o compilador pegar o bug, o custo, em termos de tempo de desenvolvedor, é basicamente medido em minutos. Se o bug for implantado em produção, mas ficar despercebido por algum tempo, o custo para encontrar e corrigir o erro pode ser expantoso. A indústria viu um exemplo dramático disto com o bug do milênio. A posição de Timothy é que é melhor falhar rápido, de forma que o impacto e o custo de bugs possa ser minimizado.

Os comentários postados por leitores indicaram ceticismo significativo sobre a praticidade da implantação contínua. Erik A. Brandstadmoen colaca bruscamente: "Na vida real, eu não acho que [sua] proposta é boa o suficiente." Um comentário no ycombinator disse: "ah... não. Talvez isso seja viável apenas para um único desenvolvedor, como um substituto para a integração contínua. Mas com múltiplos desenvolvedores enviando código, em um sistema complexo seu sistema irá cair. Muito."

Em resposta aos céticos, Timothy escreveu sobre como IMVU continuamente implanta seu sistema. O processo começa com integração contínua para construir e testar novas mudanças rapidamente. Uma das chaves são testes automáticos extensivos e extremamente confiáveis. Eles empregam uma fazenda de máquinas de teste para manter o tempo de execução de toda a suíte de testes abaixo de 10 minutos. Assim que todos os testes passaram, a implantação começa.

O código é sincronizado nas centenas de máquinas do nosso cluster. Tempo de médio de carga, uso de cpu, erros php e quedas e mais são lidas pelo script de sincronia, como uma linha base. Um link simbólico é ligado em um pequeno subconjunto das máquinas jogando o código para execução para seus primeiros poucos clientes. Um minuto depois o script lê novamente dados através do cluster e se houver regressões estatisticamente significativas a revisão é automaticamente revertida. Se não, o código é colocado em 100% do cluster e monitorado da mesma forma por mais cinco minutos. O código está agora rodando e 100% distribuído.

Com 60 funcionários, 30 milhões de usuários registrados e mais de um milhão de dólares por mês em faturamento, o que IMVU criou é certamente não trivial. Baseado em um exame por Michael Bolton e James Bach, o sistema também não é perfeito. Elisabeth Hendrickson coloca isto em contexto ao apontar que perfeição não é exatamente o objetivo do sistema.

Joe Ludwig, um antigo arquiteto do Pirates of the Burning Sea, escreveu dois artigos examinando o que seria realmente necessário para se fazer implantação contínua em um ambiente com código cliente pesado. Ele inicia com a descrição do processo de implantação de sete horas e meia de 'Pirates' e menciona o que seria necessário para reduzir isto para uma hora. Em seu segundo artigo, ele descreve algumas das mudanças técnicas importantes que seriam necessárias para fazer a implantação de uma hora uma realidade.

Qual é a sua experiência com implantação contínua? O que tem que mudar nos sistemas em que você trabalha, para fazê-los continuamente implantáveis? Deixe um comentário e compartilhe.

• Mais antigos >