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.